TDD? Waste of time!
Test-driven development is extremely costly. Yet, it is the religion of our profession, encouraged even when the benefit-cost ratio is low. Should we stop doing it? Can we make testing cheaper?
Testing is important. Every single programmer does it. Trying out your code with various inputs is the testing every single one of us is familiar with.
Writing automatic tests is a waste of time in 99% of cases.
Yes, automatic tests have following benefits in comparison with “testing by hand”:
- You write the test once and can run it million times. If your code changes due to code review or refactoring, you can just re-run it.
- It can serve as a record for code review that you thought of all the corner cases.
- When making a new feature, they serve as proof you didn’t break the rest of the system.
Tests come at a significant cost as TDD programmers spend as much as half of their time writing tests.
That may be acceptable if we run the test a hundred times. TDD encourages, however, writing mostly unit tests.
When we refactor the unit, we usually intentionally change its contract and tests fail as expected, which is useless.
Failed tests are useful only if they fail unexpectedly.
If we take the real cost of automatic testing into account, the well-known ice cream cone anti-pattern doesn’t look like an anti-pattern anymore.
Most bugs are caused by wrong interaction between units rather than faulty units. Especially with functional paradigm.
Can we do better?
Still, the idea of having automated tests would be appealing, only if it weren’t so costly. You can’t commit a manual test to a repo, you can’t easily verify it on a code review.
Could we make writing tests as simple as testing manually?
Cool things are happening in the testing field right now. It started with clojure.spec, which can generate your tests from simple invariants you state about your code. It is the next thing we will learn Clojure, and you should check it out.
And then, there are cool new Jest Snapshots! Imagine that you could record your manual testing and then just commit it to the repo. Well, it is almost like that with Jest Snapshots.
What's their biggest benefit? No more painful rewriting of tests. You just recreate the snapshot as simply as that.
I am excited that Rogelio Guzman, a core contributor to Jest and engineer from Docker, is coming to ReactiveConf this year. He is going to tell us more about Jest Snapshots and the future of testing. I hope he’s got some ideas how to finally make automatic tests cheap to write and maintain!
If you are as excited about Jest Snapshots as we are, snap up your ticket today! Save 10 % using discount code Guzman4Reactive at checkout.
— By Samuel Hapák and the ReactiveConf team
