Why Test Your Code?

18 Apr 2019

I was asked today ‘do we need to test this internal page just for developers?’ and that got me thinking about why I encourage testing. I’ve been practicing TDD/BDD since 2004 and this article is the response I should have given.

In order, my top reasons for testing:

To clarify my first claim that tests teach design and encourage good architecture:

Warning: It took me years to figure out how to achieve balance between value and total test maintenance time. Bad/slow/flaky tests can kill morale.

Some hard fought lessons follow.

Don’t test the view in server-side ‘unit’ tests!

Absolutely have integration level tests but keep them lean and healthy.

…Warning: Maintenance costs of Selenium tests are extreme unless you have white-hot automated testers with years of experience learning in the field (hopefully at some other company that has your exact stack). Even with a hardened team of QA/Testers/Breaker/SDETS maintenance of Selenium or any other full path/no stubs test suite will be far more expensive than other levels of testing.

As a way of explaining, here are some questions to ask when an integration test fails:

Also, if your project relies on vendor APIs… Oof. Maybe they have a test server (best of luck) or you stub and hope the vendor announces api changes.

Despite all the disadvantages of integration tests, they really do catch a lot of bugs when done well or even decently. Other times they are crazy time sucks with little benefit. It’s shocking how fast one state can transition to another but that is a whole other article.

So, should the developers have tested that ‘internal page just for developers’ given the above thoughts?

Disclaimer: I haven’t done enough React/Angular/New Hotness Javascript to know if any of this advice applies. My experience is mostly with Ruby (sometimes on Rails), Clojure, and Java systems.