3 ms·
Another factor is the complexity of the tests. If you really want to cover as much of the cases as possible in your tests, you end up all this bespoke mocking,
by nightowl_games 6y ago
Another factor is the complexity of the tests.
If you really want to cover as much of the cases as possible in your tests, you end up all this bespoke mocking, spying, argument capturing and asserting stuff. Your test suite tends to be completely designed around some third party mocking library. True TDD evangelists will tell you that you will learn to write your feature code to enable the usage of the mocking library to test it. That is giving a lot of power to your mocking library.
It is a substantial effort to onboard your team to the unit testing framework. It is a substantial effort to read the unit tests and review them.
At a lot of shops, it's an unspoken fact that the tests are more complex than the feature code. That the tests take longer to write than the feature code. And that frankly no one really cares if you just skip a whole class of tests because you couldnt figure Mockito out.
The test suite ends up being huge. The code inside the test suite only makes sense to a small subset of the developers and the large majority of the test suite never actually produces value. We've all seen the teams that ignore their failing test suite. We've all seen the team that spends a sprint trying to speed up their test suite.
I cant prove it, I dont have data, but in my opinion, these giant, unwieldy test suites are largely a by product of the lack of strong typing in javascript & python.
The thing that I hold near to my heart on this topic is that no system is better than having an architectural leader on your team who can answer questions and guide the team. Our task is to create higher level languages that allow a single leader to review more code, because each code review is smaller. By creating "bolted on" systems like Unit Tests that produce physically more code, we are wasting the architects time. Over time, I believe we will move towards code that is trivially verifiable on sight, and we will move away from code that is complex and hard to manually verify.