some/any, every, none assertions about chai-enzyme

[marcodejongh]

You could write a assertion with descendants because it accepts a enzyme selector. I think the following would work:

const actual = expect(<MyComponent {...{ adminPath }}).to.have.descendants({ href: adminPath });

Although I'm not sure if href is a key or property in this case. It will only work for properties.

Besides that, if you want to do any kind of sane UI testing with Selenium you're gonna be adding those same id's & classes that would have made this unit tests easier to write. In the end the team should write testable code, having good identifiers on the elements you want to test later on is part of that.

[ljharb]

Any reason expect(actual).toHaveNodeWithAttr('href', adminPath) and expect(actual).not.toHaveNodeWithAttr('href', adminPath) couldn't work by adding a single invertable assertion to chai-enzyme? (altho toHaveNodeWithProp might make more sense)

[robwise]

@ljharb That seems like a good way to go as well!

@marcodejongh Whoa, this is definitely useful. I didn't think of writing it that way. Thanks! And if you and your team see no reason not to use ids to make tests easier to write, maybe I should get my team to re-think our policy. I can definitely see how much easier these tests would be if we could just do find('#someId').

[marcodejongh]

@robwise I think something along the lines of @ljharb's proposal would work. But it's only delaying the inevitable, unless you're absolutely sure you never want to UI test.

[alex35mil]

My only issue with ids is that we're going back to the problem which was just solved by CSS Modules: you need to think about uniqueness of ids.

1. It's not a problem in context of component-oriented js unit testing, but it's not standard compliant in context of document (ok, I'm a bit pedantic here, but there is # 2).
2. If you're using it in unit testing, you'll be using it in integration testing, and here we have a real problem.