Test Driven Development

The technique of TDD

1 Write a failing test to prove code or functionality is missing from the end product. The test is written as if the production code were already working, so the test failing means there’s a bug in the production code. If I wanted to add a new feature to a calculator class that remembers the LastSum value, I’d write a test that verifies that LastSum is indeed the correct value. The test will fail to compile, and after adding only the needed code to make it compile (without the real functionality to remember the number), the test will now run, and fail, because I haven’t implemented that functionality yet.

2 Make the test pass by writing production code that meets the expectations of your test. The production code should be kept as simple as possible.

3 Refactor your code. When the test passes, you’re free to move on to the next unit test or to refactor your code to make it more readable, to remove code duplication, and so on.

Traditional Unit testing

With TDD:

The Three Laws of TDD by Robert Martin

TDD asks us to write unit tests first, before we write production code. But that rule is just a detail. Consider the following three laws:

First Law You may not write production code until you have written a failing unit test.
Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
Third Law You may not write more production code than is sufficient to pass the currently failing test.

Notes about TDD

Done correctly, TDD can make your code quality rise, decrease the number of bugs, raise your confidence in the code, shorten the time it takes to find bugs, and improve your code’s design.

If TDD is done incorrectly, it can cause your project schedule to slip, waste your time, lower your motivation, and lower your code quality. It’s a double-edged sword, and many people find this out the hard way.

To be successful in test-driven development you need three different skill sets: knowing how to write good tests, writing them test-first, and designing them well.

TDD helps you make sure that the code coverage of your test code is very high (close to 100 percent of logical code).

Use TDD Selectively

Everybody needs to try TDD, it’s extremely helpful for some scenarios, and not for others…
If I have a pretty mature idea of what needs to happen, then TDD is fantastic because I can write out what I expect, and then I can make the code work…

The opposite scenario where I find it less helpful is when I’m not quite sure what I want, so writing out what I want is going to be hard and probably wrong. I find myself in what I think is kind of a wasted cycle of writing the wrong thing, making the code do the wrong thing, realizing it’s wrong, writing the new thing that I expect which is probably also wrong, making code do that, and then repeating that over and over”. When you get into a loop like that, you need to stop.

Just brainstorm, or play around with the code a little bit, and then see what the test could look like once you have a good idea of the direction it is going.

16.07.2020