Support for classes(), etc

[tim-hutchinson]

This came up in #118. We've found it easier to work with tests that use the assertion library's comparison functions, rather than the comparison functions like hasClass, hasProp, etc.

I'd like to propose adding helpers that are more like html() and text() that simply return a consumable form of the element feature requested. IE, classes() would return an array of class names on the element. I've got an implementation of classes and can submit a PR for it and others that make sense, but wanted to see if it made sense before going further.

[eddyerburgh]

I agree. Value assertions are more useful than boolean assertions.

We could replace hasClass, hasAttribute, and hasProp with classes, attributes, and props.

We've got a good opportunity to remove these before the official release.

The one method I think is useful is hasStyle, because it allows you to check hasStyle('color', 'white') instead of returning {color: 'rgb(255, 255, 255)}

What do people think?

[lmiller1990]

I haven't had much occasion to use attributes or props, but I'd be for including them - props seems like it might be handy. classes is solved in #118 , and should probably be renamed classes in light of the updated functionality.

I agree that hasStyle should stay, I have used it quite a lot (changing button colors, opacities, and the such).

[vouill]

I personally prefer the notation getClasses() but other than that i like it too.

[eddyerburgh]

I also prefer the notation getClasses.

What do other people think?

[tim-hutchinson]

The getX syntax seems different from the conventions used in this library already (html, text).

Alternatively, it could go fully the other way and implement the functions as getters, so they would expose a property-like API expect(wrapper.classes).to.eql(['foo', 'bar'])

[eddyerburgh]

I've changed my mind, as you said we already have html and text methods.

[eddyerburgh]

This has been released in 1.0.0-beta.6 🎉. Thanks @tim-hutchinson 😀

Happy to continue discussing API, but I find:

wrapper.props().someProp

Is more elegant that

wrapper.getProps().someProp

Plus we can extend the props method by adding an optional param:

wrapper.props('someProp')