This content originally appeared on Level Up Coding - Medium and was authored by David Rodenas, PhD
It focuses on a kind of test that drives all the development, reduces time wasted in communication between roles, and improves leadership. The key? The focus.
Few months ago I wrote in the whiteboard of my room the following two sentences:
- With TDD, when you write the last line of code, you have finished,
- Without TDD, you have just started.
I wrote those sentences after being involved in a project with very little or almost not useful testing. Walking through that code was like walking through a minefield: each new development or change rose new bugs, or old bugs. It was the quite opposite experience from the one that I get used to: leverage on tests to quickly and safely update the code. That experience make me realize how powerful and fast a good TDD is, and, although seem contradictory, do not spend time in TDD is, in the long run, a waste of resources.
Is there a Wrong TDD?
Surprisingly both projects were supposedly built with TDD, but it happened that each project was built with a different flavor of TDD. The first created bad tests and code hard to maintain. The second created useful and reliable tests, and consequently, a code with almost no technical debt.
And it turns out that there is such thing as Wrong TDD, and Good TDD.
How TDD can become Wrong TDD?
The difference between the Good TDD and the Wrong TDD is small, and it is only one concept: the focus.
The Wrong TDD focuses on testing, and overlooks the rest. It seems counterintuitive because TDD is in fact Test Driven Development — did you have seen the word test in the name? — , and Test is the first word. But Test is only a part of the TDD, the rest is how we drive the development with those tests. And that affects how we test and the whole product development. If we focus on the T off TDD, we fell into the Wrong TDD.
Most developers focus on testing the code. It is natural to them: is what they know, and code is what they do. If you are a coder it is easy to write code that tests code, it is the path of least resistance. Following that path, the development ends when they have a fabulous suite of tests that tests each class, function and method of the code. But not of the application.
The same problem appears with QA Engineers. It seems strange, because TDD does not seem to apply to them, but that is untrue, because they build the testing code. When they focus on the test, the tests lose value.
It turns out that when we obsess with the test part of the TDD, it becomes Wrong TDD.
The Test has more values that it seems. When we focus on the T of TDD, we forget about the most valuable part of the test.
Where the Test value resides
Focusing on the Test is not enough to make Good TDD. More specifically, we have to do the kind of test that drives the development. And that has a lot of consequences.
The development is not just writing lines of code, it spans the entire process, from the moment in which someone imagines a new functionality, until it hits the market.
Test are not something meant just for developers, but for anyone on the project. When the idea starts, probably in the business part of the project, it has an objective. And, if it has an objective, it can be tested, just think about the Measure part of the SMART mnemonic. That is our starting point, and that should be what tests looks like: a test shows that the product does what business has an objective.
Think how wonderful it could be to align completely all stages of your development project with your project objectives. That is the real purpose of TDD, and where it gets all its own potential.
Tests value grows in the Good TDD, because it makes your objectives drive all the development.
What I loose with Wrong TDD?
In some cases the Wrong TDD does not seem bad at all. In the best-case, it gives a small extra layer of security. In the worst-case, it looks like that we are loosing time; and we stop doing TDD. But we are loosing more than that.
The first victim of the Wrong TDD is the agility and the development speed. If we are doing Agile, having good tests is essential. Each change, each new development, each new feature may require some rework. Good tests are essential, and developers should leverage on them and create new and better code. Without them, the code deteriorates, the development speed decreases, and the phantom of a big refactor starts to shadow.
The second victim is understanding. With the Wrong TDD the objectives are not equally clear for everyone. Business may have one idea, the developer may understand something different, and QA something else. Each actor plays independently and misunderstandings raises. Developers have to talk more with business or be creative with the product, QA refuses developments because they have different criteria than developers. There are lots of redoes and reworks, the product ends looking like a big compromise.
With the Wrong TDD we lose time everywhere, and the project looks like it lacks leadership.
How is the Good TDD?
The Good TDD focuses on the objective. Not in the application, not in the code, but in the final objective of why it is developed.
The developer has to forget about testing code —functions, methods and classes—, he has to think about the objective. The test that he writes should be a reflection of the objective of the product. With the right test, the developer builds exactly what he needs to build, no more, no less.
Note: I have discovered some time ago a simple and quick argument against those that believe that you have to test each public interface, function, method: with TDD the code did not exist before the test, so, it is impossible to test each public interface, function or method if there was none.
The QA engineer has to think that he is one developer more, but instead of writing code, he writes the code for tests. He has to use TDD, that means that he has to start writing tests before the developer finishes. And thanks to that, the QA engineer provides all cases to the developer, and more important, keeps business up to date.
And the last actor, business. He is who defines the objectives and who knows what is really relevant or not. In the Good TDD, he is the one who starts writing the tests.
Business is the fundamental role in TDD.
How convert Wrong TDD into Good TDD?
Business is the key, he must write the tests. It seems strange, but it is easier that it looks like. And of course, tests do not need to be written in code, but they must be clear enough to know what to test once the feature is done.
The Waterfall mindset tells us to write tons of documents and specifications. We believe that we have to explain the things thoroughly, so the others can understand them, but although what our common sense say, it is impractical. Once we write a document, we can share it with other people, but each person has its own ideas and ways to see the world. We do not have any guarantee that anyone in the project will understand the same from the same text. In fact, we can guarantee that anything that can be misunderstood will be misunderstood, and worse, probably everything else too.
The idea behind of the Good TDD is to use the test as documentation. But not as code, but as examples of how things works. Examples are concrete things, very difficult to be misunderstood, and very simple to share across the process. Business should write those examples of usage, those that aligns with the objectives, and those that allows to measure the success of the project.
Once we have the examples, the rest of roles follows the same examples.
The developer does not focus more on testing the code, but the objective of the product; because tests are theexamples that business have provided. The code is constructed because those examples needs these changes to work. The developer now has a direct job, from start to end, a straight line that he can follow until having the result.
The QA Engineer now knows exactly which cases are relevant. He even knows that the developer knows that. Both are aligned and have the same objective. Because of it, the QA Enigneer can work before the developer ends, and participate in the TDD.
The main value of the Testing is to communicate all roles, with examples, without ambiguity, and keeping everyone in the same page. And the Good TDD enables it.
Summary
The most effective TDD is the Good TDD. The difference between the Good TDD and the Wrong TDD is thin. It is easy to start with the Wrong TDD, and achieve one point in which you think that you already know TDD, or even believe that TDD is not for you.
Go one step further and get the big picture, because the difference between the Good TDD and the Wrong TDD is the focus.
TDD is not just about coding, it is about the whole product development. Stop loosing time and resources at every step. Use the test as a tool to communicate all roles in a project, and create the examples to keep everyone on the same page. Starting with business.
The Most Effective TDD was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by David Rodenas, PhD
David Rodenas, PhD | Sciencx (2021-11-07T20:04:35+00:00) The Most Effective TDD. Retrieved from https://www.scien.cx/2021/11/07/the-most-effective-tdd/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.