On Tests

If you have to choose between tortured, hard-to-read production code and tortured, hard-to-read tests for that code, it is better to have bad tests than bad prod code. This is rarely a mutually exclusive choice.

That is not a contentious claim, but the corollary is: if you have to choose between no tests at all and tortured, hard-to-read production code, it is often better to have no tests.

Perfer mocking as a means of changing behaviour in tests. If your language doesn’t have good support for mocking and a strong community/set of norms around that process, I’m sorry for you.

The time taken to write tests will never be enough (if you’re being a responsible professional and prioritising the work that makes your stock options appreciate benefits the company the most) to write the best tests possible. As a result, “how should I test” should always be an exercise in “which of these bad options is the least bad?” If you don’t feel that way, ask your manager for more work. I’m serious.

There can be no general answer to “what kind of tests should I write?”. It’s always case-by-case. If you’re positive that you need a unit test but the only tests available to pattern-match from are integration tests and you need to make it into the release in an hour, copy/paste an integration test, sigh, adapt it, then go out for drinks.

If you’re testing code that is “shallow” stack-depth wise, and “deep” in terms of the number of datastores and side effects it performs, integration tests will likely be more valuable–as in, they might catch more bugs and serve better as documentation for how to use the code under test. Both integration and unit tests for such code are likely to be hard to write, since the former will have to set up a lot of data and the latter will have to mock out lots of things, but the unit tests may not be as useful since the code could end up over-mocked.