Create chai assertion plugin

[lelandrichardson]

Potential API:

chai.use(require('reagent/chai'));

expect(wrapper).to.have.props({ foo: "bar" });

expect(wrapper).to.have.children();
expect(wrapper).to.not.have.children();

expect(wrapper).to.match('.foo.bar');

expect(wrapper).to.be.empty;
expect(wrapper).to.not.be.empty;

[ljharb]

I assume to.have.all.props and to.have.any.props could be supported as well? also, expect(wrapper).to.contain(foo) / expect(wrapper).not.to.contain(foo), and expect(wrapper).to.be(Foo) / expect(wrapper).not.to.be(Foo).

[lelandrichardson]

yes. excellent! We should get a list of the desired extensions and implement...

[benbayard]

Hello! I am currently working on an enzyme-chai framework. I call it chai-shallowly!

Currently the API looks like this:

    it("should render the correct type", () => {
      expect(component).to.shallowly.match("span");
    });

    it("should set default classes on the element", () => {
      expect(component).to.shallowly.haveClass("prod-ProductHelpFlyoutButton inline-block-xs");
    });

    it("should render the correct type of children", () => {
      expect(component).to.shallowly.haveComponent(Flyout);
    });

I am likely going to spin this in to its own repo though, not inside reagent.

What do you think?

[goatslacker]

How about also having one with a better API like assert?

[lelandrichardson]

@goatslacker when you build a chai plugin, it automatically adds them for all three of its APIs: expect, should and assert

[goatslacker]

Well that's badass. TIL

[benbayard]

@goatslacker what said @lelandrichardson is correct. Some of what I am doing is name spacing (e.g. haveClass vs .have.class ). I'm working only on porting over shallow rendered portion.

[vesln]

chai.js core dev here.

here at product hunt, we've built an internal project, quite similar to enzyme, and we are now looking to migrate.

we already have custom chai.js assertions for our internal project, and porting those for enzyme will be quite straight forward.

if you are interested in a collaboration, let me know.

edit: some assertions we use

to.have.tagName
to.have.html
to.have.style
to.have.text
to.have.value
to.have.css
to.have.attr
to.have.props
to.have.component().with.props()

most of the stuff from https://github.com/chaijs/chai-jquery is applicable too

[benbayard]

We are currently working on moving this from internal testing to external
open source. There are just a few more improvements we will need to make.
I'll keep you updated.

[ljharb]

@vesln that sounds awesome! As you migrate the chai matchers, could you ensure that none of them end in properties, ie, they all require a terminal function invocation?

[vesln]

All, we just open sourced our chai.js assertions for enzyme. Feedback/prs/feature requests/issues are very welcome!

@ljharb lmk if you are ok with including it in the docs so more people can discover and leverage it.

I'll update chai.js's website later this week as well.

[ljharb]

@vesln awesome! The only issues I see are to.be.empty and to.exist - our styleguide's eslint plugin prohibits these (noop expressions) and airbnb/javascript#646 and #97 (comment) talk a bit more about why they should be avoided. Should I file an issue on chai-enzyme directly?

Otherwise, a PR would be welcome to add it to the docs :-)

[vesln]

@ljharb the issue is that those methods are already getters in chai.js itself and we cannot redefine them.

what i can do tho is alias them to .to.be.blank() and .to.be.present(). sounds good?

[ljharb]

sure, that sounds awesome - i have no objection to mentioning exist/empty in the chai-enzyme docs either, as long as there's alternatives :-)

[vesln]

👍

[lelandrichardson]

Closing as there is now: https://github.com/producthunt/chai-enzyme