After asking for help in the Elixir community about tools to do TDD, I was presented with a conference video from a community member I have great respect for.
TDD - Where did it all go wrong
The title is catchy, but be not afraid - this talk actually defends TDD.
In it, the author pin points the major problems with TDD and then searches for solutions for those problems.
He also explains how people are doing TDD wrong and how they can improve it.
Looks nice, why are you confused then?
However, one of the things I took notice is that he mentions that in TDD, The test unit is the feature, the thing you should test is the feature.
Some may know this better as Test the API, not the implementation. You may create tests for the implementation, but delete them after.
Looks straightforward, right?
Wrong. If I take the feature ( or behaviour or what have you ) as a Unit I want to test - instead of a module or a function or whatever it is you defined to be a logical unit in your code - then what I actually end up is with a suite of Integration tests.
See it this way: if all you test is the public API of your webpage, then all you are really doing is a bunch of integration tests that traverse your entire system given a query ( or worse if you mix queries with commands, but that’s another story ).
Integration tests are a scam and in fact most people seem to say that a common problem is that fact we have too many of them and too few unit tests.
But if a Unit test is only testing the end result of everything, then it is testing the whole system. This is mindblowingly confusing to me.
- How do you do TDD right then?
- If modules, classes and functions are not units, what is?
- How to not fall into the dark abyss of the inverted pyramid of testing?