TLDR; Existence of untested code in the wild should worry you: most of our lives is software controlled in a way or another. Good news is that you can do something about it. Bad news you may be doing it wrong.

Disclaimer

I understand that I am addressing a very sensitive topic; I will probably offend many readers that will say that I am an insane troll and my views are bullshit. Offending is not my objective, but I stand by my opinions. Of course comments are here to for you to voice your opinion. And yes this piece is biased by my past experiences, but that’s the value of it, sharing my experiences.

‘How legitimate are you?’’

Fair question. I have a 35 years long career in IT; I have worked at companies of various sizes and culture. I have often been in some transversal position and had the opportunity to meet and work with a lot of developers (think thousands). While most of my roles involved code, I also touched on QA and BA activities. I am now in CTO-like positions for 2500 ITs and had the great privilege to work with well-known french experts, as well as lesser-known ones.

So my point of view is based on things and events I have experienced first-hand as a developer, things I have seen others struggle or succeed with, problems encountered by teams I have helped and views and issues that other experts taught me about. Basically, I have been through all this sh*t and made most of the mistakes I list here. Of course, this does not demonstrate how right I am, but at least, please agree that I have a comprehensive view of what I am talking about.

Some fallacies about unit testing

1. TDD is all about unit tests

Unit tests, really?

Big NO, TDD, a.k.a ‘Test First Development’ is about defining what the code is expected to produce, capturing this as some test(s) and then implementing just enough code to make it pass. Unit testing is understood as testing small parts of the code in isolation, e.g. testing some class’s methods, maybe using some stubs/mocks to strip dependencies.

Unit tests

Unit tests are promoted for their speed and focus: they are small, with limited dependencies, hence run (usually fast). When a unit test fails, it is easy to identify which part of the code is responsible (for the problem).

TDD is actually about every form of tests. For example, I often write performance tests as part of my TDD routine; end-to-end tests as well. Furthermore, this is about behaviours, not implementation: you write a new test when you need to fulfil a requirement. You do not write a test when you need to code a new class or a new method. Subtle, but important nuance. For example, you should not write a new test just because you refactored the code. If you have to, it means you were not really doing TDD.

And when Kent Beck wrote about tests being isolated, he meant between one and another. For example, having one test inserting records in a table while another reads that same table is probably a bad idea, as the result of the tests may vary depending in the order of which the tests are run.