Test Driven Development - an introduction
If you are looking for an introduction to testing, I am sorry this article will do you no good. If you know development in this order:
write application logic -> write a few tests
then this article is for you.
Test driven development (TDD) although has the same basic steps but not in the same order. In TDD developer has to write the tests first before writing the logic. This might seem silly, I can already hear you saying how can I test a method I haven’t written yet. But that is the core idea behind Test Driven Development.
Test drive the development in TDD.
So here is the deal, you have to write the tests for the methods you have not written yet and using objects you have not implemented yet, and yes they will fail, they need to fail (if they don’t fail there is a whole different problem here). Sometimes they might not even compile. This is the core distinction between TDD and no TDD, we start by writing a failing test. Only after they fail that you create objects and methods that make the tests pass. And please note here dear reader that you only write the minimum necessary code to just pass those tests.
Some of you might have noticed a scenario that TDD puts completely out of question. No? Here let me state it out when you sit to code a new method you spend a lot of time staring into blank space trying to figure out all the things that the code might have to do in present, past and future. All this speculative code that we spend a lot of time to create. Bling, you suddenly remember a lot of developers in the same scenario?
Well with TDD you just have to pass the tests. And its is quite intuitive that way if you think, you simply write tests according to what you need for your app to positively do today and then you code the same requirements based on the failing tests.
TDD gives development great clarity and focus, making you code only as much as you need to at any point.
TDD approach shifts the idea of testing as an afterthought, rather you let the tests drive the development. I know a lot of you might be sceptical, it is natural, I was too, but all I would like to say is why not try it out. After all, as developers we kill to get our hands on coding challenges and this is a challenge you won’t regret fulfilling.
You might feel like you are doing things upside down like writing backwards or something, but trust me this will dramatically change the way you develop applications.
Please note there are scenarios where TDD is not the way to go like, multi-threading scenarios, security options, testing user interfaces, some parts of game development.
For those of you who are planning to spend a month writing code and the next developing, please don’t misunderstand. TDD is not here to increase your burden rather decrease it.
As Simon Allardice stated in his course Programming Foundations: Test-Driven Development:
It’s more like Monday at 9:00 A.M. write a test. Monday at 9:00 A.M. and 20 seconds see that test fail. Monday 9:00 A.M. and 30 seconds start writing code to pass the test. Very small steps repeated often. Creating tests isn’t and should never be any kind of major roadblock, barrier or even speed bump to writing code.
It should be the tiniest amount of work. You’re just about to write a new method, you pause, you take a few seconds, you think, how would I call this method to prove that this is about to work? Or that it doesn’t work? And you would write that test. You would verify it fails and you would then start writing code to pass the test.
What do you think? How are you going to try TDD? If there anything you would like to add or change, please comment below.
Click ❤ if you enjoyed the post. Follow me to read more about software development, android app development, life and a lot more.