Before we start - I'm working on https://cloudash.dev, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching b...
For further actions, you may consider blocking this person and/or reporting abuse
Great post, really good take on the benefits and the purpose of testing!
You mentioned that if a prop name changes that you don't want your test to break, I think I may have misunderstood this but in order to render the component you would need to specify props so wouldn't a name change always break your tests?
I agree, I think it depends on the prop being changed, but I've definitely had tests break after prop name changes because I was specifically using that prop.
I would add two things to the reason we're unit testing, which may tip you towards getting that 100% coverage after all.
So to sum it up, unit tests are about a lot more than just double-checking X really does Y. That is not to say you should chase 100% coverage at all costs or by any means, of course you shouldn't. We all know that will end up with tests that mean nothing. But you better be clear about why you leave out bits and "that bit's difficult to test" is usually not a good excuse.
Though I do agree that react component tests should just test behavior, I would say that's not a unit test. Unit tests should test logic and have no dependencies. You should be testing logic directly and not through side effects of rendering a component.
Also, tests are a feedback tool. If they're brittle and break, that's a good thing -- you got some valuable feedback about the impact of the change you made to the system.
Nice one, I want to start testing a LOT more than what I'm doing now - which is nothing, nada. Now I know what not to start with, enzyme. I'll try the testing library you recommend, thanks.
Excellent post, will send it to my team first thing Monday morning :)
Thank you! That means a lot to me 🥳