Acceptance, E2E tests, yes. Unit tests, no. Arguing against shallow rendering is one thing, but here you’re now arguing against unit tests in general. You will end up with a nightmare in very large apps if you are covering the same code with 100 different tests and something breaks. This becomes apparent after several years of the same codebase…
You’ve got things a bit confused here:
I agree with most of what you’ve got in this article, except this part:
“Tests can be expensive to develop and maintain, especially when the product and code are in flux.”
This is only true in my experience for integration tests that overlap what should really be tested at the unit-test level. If…
I don’t get what you guys are saying. When you use
connect from react-redux and you don’t specify
pure: false, then that is using shouldComponentUpdate. You can use a top-down approach and use PureComponent on children, or you can do the sideways-in approach, but they are both using shouldComponentUpdate.
And, I definitely agree, it’s usually a pipe dream to think stakeholders are going to read your BDD/acceptance tests, so that’s not a good reason for doing something like wasting a lot of time on a DSL.
One rule my team still follows, however, is if it’s not something the end user would…