Your Practical Introduction to Test Driven Development These days you read a ton of articles about all the advantages of doing Test Driven Development (TDD), and hear a lot of talks at tech conferences that tell you to “Do the tests!”, and how cool it is doing them. And you know what? Unfortunately, they are right (not necessarily about the “cool” part, but about the useful part). ! The typical advantages we list when it comes to talking about TDD are real: Tests are a MUST You write better software You have protection from breaking the world when new features are introduced Your software is self-documented You avoid over-engineering Even if I’ve always agreed with these advantages, Of course, now I know I was wrong, but why did I have this idea despite the shiny magic of the pros? The reason is just one. there was a time when I thought that I didn’t need TDD to write good and maintainable software. It costs a lot The Cost It costs a lot! Someone is probably thinking “ ” — and this is right, too. But these two costs come at different times: but it costs even more if you don’t do the tests you do TDD ➡ you have a cost . now You don’t do TDD ➡ you will have a cost . in the future So, how do we come out of this impasse? The most effective way to get something done is by doing it as naturally as possible. The nature of people is to be lazy (here software developers are the best performers) and greedy, so you have to find your way of . It’s easy to say, but so hard to do! reducing the costs now Here I will share my experience and what has worked for me in turning the benefit/cost ratio to my favour. But before I do that, let’s analyze some typical difficulties in applying TDD. Are you able to test the sum of two numbers? Generally speaking, theory is not optional; you have to master it in order to master the practice. However, trying to apply at once all the theoretical knowledge you’ve previously acquired could have the following effect: You can’t spend all that knowledge at once The typical theory lesson on TDD starts with something like this: {
    [Test] SumTest()
    {
        Math math = new Math();
        Assert.AreEqual( , math.Sum( , ));
    }
} { Sum( x, y)
    { x + y;
    }
} public class MathTests public void 2 1 1 public class Math public int int int return And here you are like That’s easy, isn’t it? Then comes this: red ➡ green ➡ refactor cycle unit, acceptance, regression, integration tests mocking, stubs, fakes if you are lucky (or maybe unlucky 😅), someone will tell you about contract testingand if you are very lucky (or maybe very unlucky 😅) you will touch legacy codebase refactoring The going gets tough, but you are an experienced developer and all these concepts are not that hard to handle for you. Then class ends; you go home, and throughout the next days you diligently do some code katas to fix the concepts just learned. So far so good. The struggle is real Next comes a real-world project, with real deadlines and real timing costs — but you are motivated to apply your shiny new TDD. You start thinking about the architecture of your software and start writing tests for the first class and the class itself — let’s call it . Class1 Now you think about the first user of , let’s call it and again you test and write it. is a collaborator of , so are you going to mock it? Ok, let’s mock it. But what about real interactions of and ? Maybe you should test them all as well? Let’s do it. Class1 UsageOfAClass , Class1 UsageOfAClass Class1 UsageOfAClass At this point, inside of you, you start hearing a little voice that says “ ”. You don’t listen to this evil voice and proceed straight to the next test. I would develop much faster if I didn’t have to write these tests… is going to be used by and it persists itself inside a Db. So, do we have to test , its interaction with , and the persistence in the Db? But wait… did anyone mention how to cope with I/O testing during the TDD theory class? Class2 UsageOfAClass Class2 UsageOfAClass Ok, I quit The theory behind TDD is not that hard to understand, but applying it to the real world can be really complex if you don’t approach it the right way. Just do it We should always keep in mind that theory must be bent to our needs and not the contrary. The main goal is to get the job done. So my advice is, ! just do it Then, when you get stuck in some theoretical mind loop like: Start simple and just do your task up to the end. is this a unit or an integration test?here should I mock it or not?oh crap, here I should write a new collaborator, so a brand new suite of infinite unit tests just to write “hey, banana”… Just forget about theory for a while and take a step forward. Just do it as it comes! Once you are done with your task, have a look back at your work. at the completed job, it will be much easier to analyze what would have been the right thing to do. Looking back Practical TDD Just do it. By the way, I think this is also the right approach to TDD. What was wrong in how we built , and ? Class1 Class2 UsageOfAClass The approach. This is a bottom-up approach: analyze the problem figure out an architecture start building it from unit components This approach is the best friend of . You typically build the system in order to prevent changes that you think will come in the future, without knowing if they actually will. Then when some requirement changes, it typically happens in a way that doesn’t fit your structure, no matter how good it is. over-engineering For me of writing with TDD has been to take a top-down approach: the key to drastically reducing the immediate cost bring a user story write a very simple test of a use case make it rungo back to step 2 until all use cases are complete While doing this process, don’t worry too much about architecture, clean code (well, remember at least to use decent variables names) or any kind of complication that is not currently needed. Just do what you know you need , up to the end. now Tests of the story clearly state what are the current and known requirements. Once you are done, take a look at your big ball of spaghetti mud code, get over the shame, and look deeper at what you have done: Look at what you have done It works! And tests prove it.All the system is there, . and just what is actually needed to get the job done Now you have an overview of all the parts of your system, so you can refactor with the knowledge of the domain that you couldn’t have had when you started from scratch. And tests will make sure that nothing will break while refactoring. Refactoring The best way for me to start refactoring is to identify areas of responsibility and separate them into private methods. This step helps identify responsibilities and their inputs and outputs. After that, classes of collaborators are almost there and you just need to move them into different files. As you proceed, write tests for the classes that pop out from the process and iterate until you are satisfied with the result. And remember, if you get stuck somewhere, just do it! If you do something bad, once you are done you will have more information on how to get over the mistake the next time you face it. , to the best of your current abilities. Getting the job done is the priority This way, if you analyze your errors to learn from them, you will also refine your abilities. The next user story Continue developing your product following these steps: take a story make it work completely in a “test — code” cycle refactor While adding features you will continue to change your software and maybe even its structure. But as the system grows, the cost of change will maintain a linear growth thanks to the two main features of TDD: architecture discovery (that helps to control the complexity) protection from breaking changes The system will not be over-engineered, as architecture is going to emerge as stories get completed. You don’t think about what could be future requirements; if you end up needing it, then the cost to implement it will be low. What can make it go wrong? The size of the story. What you build up to the end must be the right size. Not too big (otherwise it will take too much time to get any feedback) or too small (otherwise you won’t have the overview). What if the story is too big? Split it up in pieces that can be built from the start to the end. Please share your opinion and suggestions about this article. Do you agree with me or do you think that all this is a bunch of rubbish? Let me know what you think in comments; it would be very nice to start a conversation on TDD and share our experiences. Thank you for reading! Image credits to https://testsigma.com/blog/ai-driven-test-automation/

Ball

BUNCH

Discovery

Read My Stories

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

The Untold Truth of Test Driven Development

Too Long; Didn't Read

Companies Mentioned

Luca Piccinelli

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

The Untold Truth of Test Driven Development

Too Long; Didn't Read

Companies Mentioned

Luca Piccinelli

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES