Avoid TDD, it is evil.

A year ago, while reading topics related with Material Engineering , I was captivated for what is defined as “the hardness of a material”, it is:

The resilience of a material to be scratched.

The book talked about extremely hard materials on planet Earth, for example: Diamonds. A diamond is so hard (virtually can’t be scratch), that with the minimum amount of force, it breaks. This leaved me with a very interesting paradox — to call it some way —

~ The hardest material in planet Earth is also the most fragile. ~

What this has to do with Test Driven Development (TDD)? Well, it helps me to create a good analogy between TDD purists vs the rest-of-the-humanity. TDD purists overreact about the idea of developing without writing a test first, justifying that:

focusing primary on the unit tests drives the code design.

Also, they think that everything “slow” like hitting the DB is a super bad idea and has to be replaced with an ocean of intermediated objects like dummies, stubs, mocks, spies… you name it. And of course, If you violate any of these rules, you should be slaughtered for being a very bad engineer.

The above creates what I call:

~ The Diamond Effect ~

TDD uses such a rigid approach that as a result it gets extremely “fragile”. With “fragile” I mean that the approach only hurts your designs and consumes time like crazy, without giving you a proportional benefit.

So, what to do then?

First things first: We have to acknowledge that TDD — as people currently understand it — has room for improvement, and last but not least, it is old fashioned.

Secondly: We need to establish a modern version of what TDD should be, matching our current needs and available technology. Personally, I consider that the most efficient way has 5pillars, which are:

1Development-time matters. Spent time means spent money, and money is a very fixed resource. The easiest creating tests could be, the less time will take to be written. Less time = more money.

2Decrease the amount of test types that currently exist, and just use two types: System Tests and Unit Tests (*)

3(*) The old-fashioned-idea that fast tests — using the ugly intermediated objects — are better than “slow” tests — hitting the DB or doing any I/O related transaction — has to change. Hitting the DB is good: it simplifies everything and does not compromises the design.

4There is not such thing as “slow” tests. We are in 2017, there are plenty of tools in the cloud and tons of SaaS platforms with a big computing muscle at very affordable prices. So, the whole idea of “fast” vs “slow” is just obsolete.

5 We have to think forward the idea of simplifying test creation. If it could be easy enough, then, more companies and engineers will be willing to use it. And that benefits all of us.

So, in your next project (or even in your current one), propose these ideas, start using them, explain them and remember: hitting the DB, is not bad and avoid writing test first neither.

Test, test and test!

Side note: If after reading this post you still do not get why writing tests is important, then, it is a good time to read this.