So I am new to agile, but not test-driven development. My professors in college were all about the idea of tests then code then tests. I am not sure I understand why. From my perspective it is a lot of upfront cost that will most likely be changed as your code evolves.
This is how I imagine TDD and why it confuses me. If I were to build a house as a TDD contractor.
-
Give me all of your specs (stories).
-
Get approval on the specs.
-
Break down all the specs into inspection I think I will need (see into the future).
-
Call an inspector to look at those points and tell me right now I am failing the inspection (gee thanks).
-
Start building the house.
-
Call the inspector back out daily (passing 2/100).
-
Oh shoot, there was an issue with my understanding and now I need to add 9 more inspection and change 27 of them.
-
Call inspector passing 1/109.
-
Damn it. Why doesn't the inspector like this one… oh I updated that method name…
-
Build some more.
-
UGGGGHHHH MORE CHANGES let me update the damn inspector. Oh I am failing no s**t.
-
Am I done yet?
Okay, that may be outlandish, but I just do not see how I should know all my methods and how things will work until my code is there. 99% of the time I have to go back and update a unit test any ways and add more as I go. It just seems backwards.
What seems more appropriate is DDT or development-driven testing which is a thing the community has all but forgotten about it seems.
From my understanding DDT for a house would look like:
-
Give me all of your specs (stories).
-
Get approval on the specs and break them out.
-
Start a unit (the foundation).
-
Take notes (comments) of some tricky logic.
-
At the end before beginning the next unit have the inspection (create a test).
-
Fix any issue found and inspect again.
-
Approved this unit move onto the next.
If we are all being honest doesn't that sound more human and centered on the developer and business? It seems like changes can be made faster and without the overhead TDD seems to create.
Best Answer
One of the benefits of a TDD approach is only realised when you also do emergent design.
So in your first analogy, you wouldn't write 100 tests, as there's no possible way that you'll know what your software will look like.
You write one test. You run it. It fails. You write the smallest unit of code to make your test pass. Then you run your test again. It passes.
Now write the next test, repeating the process above.
This might seem like a wasteful approach at the very beginning, when it's obvious what your code is meant to do, but the great thing with this approach is your test coverage is always high, and the code design is cleaner this way.
As a method, it goes hand-in-hand with pair programming; one pair writes the test, the next writes the code to make it pass, then writes the next test, and so on.
I even use this approach when writing a new class; the first test is a call to initiate the class constructor. But I haven't yet written the class, so it fails. Next I write the simple, empty class, and my first test passes.
Once you get into the mindset, it is very difficult to not be in it and code the "old fashioned" way.
I'd recommend working in a good Agile environment to learn this, or reading a few good Agile books (Clean Code and Clean Coder are both very good) to better understand.