Write tests. Not too many. Mostly integration.
Kent C. Dodds
5.6K20

Glad to see an article about testing promoting this approach. I’ve been using it myself for the last 4 years on 3 different teams over 3 different web apps. The common themes across all of these projects when focusing mostly on integration tests were:

  • We spend much less time overall writing tests, and more time writing actual code. Significantly less tests are needed compared to a unit test heavy strategy
  • We became much more confident in our tests actually catching bugs, as integration tests actually make sure your app works. One integration test can easily replace several dozen unit tests. Since each test relies on all the pieces of the app working together, so there are many many ways to break a single test.
  • Almost no time is wasted on “fixing” “broken” tests after performing a refactor. This one is huge. Generally when cleaning up code that is “thoroughly” unit tested, you just expect to have a bunch of test “failures” you need to “fix”. This is actually great when you are writing a shared library with a public API with callers other than your own code. It’s a terrible waste of time if your app is the only one using the code being tested. Integration tests make performing sweeping refactors and code clean up much safer.

All of these points above also apply to using a typed language (like TypeScript) over something like JavaScript. So many unit tests I’ve seen in large JavaScript code bases are basically testing things that a compiler will just catch automatically (like, you know, don’t pass an object to that function that takes an array).

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.