Testing 1.0
Closed this issue · 13 comments
How close is 1.0? If you're not planning any major api changes from where it's at now, I could use it on a project and report issues. Not client work, so no one dies if it breaks. Let me know if that's fitting or helpful.
The main change I need to make is the breaking one: making subTree act like subTreeLike
I keep intending to work on this, but getting caught up in other things
Ha! That's the one thing was driving me crazy last night setting things up, took a while to realize you were using subTreeLike in those tests. I'm not certain I'll have the time, but I'll try to get a PR in to help with that.
@glenjamin the obvious path would be to simply make subTree do exactly what subTreeLike does. Is there some difference in your intended approach? And second, have you also considered making the 'every' behavior default as well, always returning a collection? One subTree to rule them all?
The plan is to make subTree do what subTreeLike does, yes.
I'll still keep everySubTree distinct, as in my experience a single node search is more common.
The main thing slowing me down is I want to make sure the test coverage is still really high
@glenjamin I've been using this for a large project and would glady contribute some tests and code if you give me some directions =)
I'm somewhat in two minds about this at the moment.
To move forward I need to make the breaking changes (possibly with a back-compat API), trim down the interfaces, convert all the old tests to the subTree interfaces, and then test it out and publish.
I've been keeping a close eye on enzyme lately, and they seem to be doing a good job and getting very popular. I'm half tempted to point people there instead of finishing off 1.0.
The main disadvantage of enzyme seems to be that it's not very strict about what to include in it's API - so the surface area is huge and there's some stuff in there I'd recommend staying away from (which is most of the reason for doing skin-deep 1.0 in the first place).
Interesting, I was just about to mention Enzyme, but didn't want to be that guy. What do you find worth avoiding in that lib?
Interesting, I was just about to mention Enzyme, but didn't want to be that guy. What do you find worth avoiding in that lib?
- Prefer
shallowovermountorrender. - Avoid any search method which takes JSX as an argument see. This is because
defaultPropsare weird (c7b1b5a was when we moved away from this in skin-deep - Avoid exact assertions, only assert on the props you really care about
- CSS selectors are cute, but the best approach I've ended up with is a combination of component name (or type) + a couple of props. Out of the box EnzymeSelector can only do one or the other, but you can create a predicate which does this.
- I can't think of a good use for
setContext,setProps,setState,state,contextetc apart from asserting on implementation details instead of observed behaviour
If you use enzyme, but keep your tree searches simple and your assertions focused on things that a user can actually see, things should be fine.
=( I liked the direction this library had, but I guess I'll have to migrate to enzyme and create some eslint rules to prohibit nasty DOM and markup rendering
geez, the more I look at enzyme the less I like the decisions behind it... It really feels like a collection of overlapping utility functions.
Can I convince you to keep working on getting 1.0 out?, of course I'd love to help! We can probably make the API really small and it'd be awesome.
Yeah, I think going through that list might have convinced me to do 1.0 even more!
I have a few free days coming up at the end of the week, if I can get the breaking changes done neatly then the rest should be simple enough.
awesome! Let me know what I can help with!