How not to shoot yourself in the foot
Without the use of unit tests and TDD it is very easy to shoot yourself in the foot. With tests and TDD, this is much more difficult, but if you succeed, you will be left without a leg.
Recently, on Habré published quite a lot of articles on TDD, which cause mixed reactions from readers. There are more and more words, young developers reading these articles, wander in a haze of definitions and terms, somewhere in the subconscious mind realizing that TDD is probably great.
In this article I will try to explain what the conversation is about. What is TDD and how to use it carefully.
')
What is TDD in a nutshell? - This is the developer writing tests to implement the functionality.
On the advice of Roy Osherov, we divide the question of the applicability of TDD into two:
There is not a single sensible developer who would not check it before delivering the program to the client. What is there a developer, in any production, the product is tested at least visually. Take even aircraft construction, even weaving bast shoes - everywhere one way or another the product is checked. This applies to you and me. So if we test anyway, why not automate this process? Why, after each small change, manually check all the functionality, if you can do it with one click of a button?
In our projects of developers who do not write tests, we call ChakNorris, because they are incredibly cool and we sincerely envy them.
In the code of Chuck Norris there are never bugs. He is never wrong. If you find a bug in Chuck's code - try to talk to him about it - you will immediately realize that this is actually a necessary feature of the project.
In fact, documentation is just one of the ways to communicate. Documenting the code, we communicate with the team (with the present and the future), which is working on the project. Tests are the best documentation. Developers do not read paper documentation at all, and these pieces of paper and files disappear all the time. In the written comments to the code, it is not always possible to figure out what exactly the author meant. In tests, you can immediately see how the code works, what they want to get from it.
Chuck doesn't need all this - he works alone.
What projects can you work on alone? Only on those where you bought a plane ticket to a warm country in which the customer will not find you. On all other projects you work at least together - you and you in the future. And you need to communicate with yourself on the subject of implementation. Chuck is doing very well without it - he remembers everything in his projects.
Chuck does not refactor at all, because his code is perfect at once. So there are no situations when you need to change or optimize something and try not to break anything in the process.
A strange excuse, especially after you read why Chuck Norris does not write tests.
With the help of tests you will save time. How much time do you spend now on debugging and manual testing of your applications? Yes, tests take time to write, but it pays off.
Almost everything can be tested, and what is impossible - it is not necessary. Mock frameworks are very helpful in this. Unit tests need to test logic in your project. Testing the interaction with the base, with external services and so on - this is already a conversation about integration and functional tests.
We have testers - let them test. The fewer bugs you leave to testers, the less you will work with them in the future. Work more efficiently - employers appreciate it.
Congratulations, you are Chuck Norris.
Tests save time. Tests prevent the repetition of errors. With their help, the code is documented much more efficiently and you can feel much more comfortable during refactoring.
This picture and Kent Beck’s " Clean Code That Works " phrase is all about TDD. We want our code to work, and we want it to be clean. That's all. And with the help of the steps Red-> Green-> Refactoring, as practice shows, it is easier to achieve this.
At the Red stage, we write a test, evaluate the design of our function, right there we correct it. We are convinced that the functionality is not implemented and the test fails.
At the Green stage we reach the goal - “Code That Works” - our implementation starts working.
At the last stage of the Refactoring cycle, we realize the goal - “Clean Code” and it is still “That Works” ... and we go further.
The main idea of ​​TDD is not tests at all, it is a matter of design. When you write a test, you ask yourself what you want to do and how best to implement it. Here you test your design code, along with keeping the principles of Keep It Simple Stupid and You Ain't Gonna Need It .
What TDD gives is confidence. Are you sure that the test will be written - if you write tests after the functionality, then there are a thousand reasons not to do it. You are confident in your design. You are sure that everything you wanted is realized.
Unfortunately. There are no silver bullets at all, as Frederick Brooks wrote in his book . And TDD is no exception. You can still make mistakes, you can make mistakes in tests. Unit tests will not be limited to everything, you may need integration and other types of tests. TDD is definitely not enough to cover all your code. And most importantly - you will still need to think :) And do not relax.
... described in TDD article - this is like snowboarding . In short - you need to be careful. You need to be aware of what you are doing and why. And the best option is to learn from someone who already uses this approach. If this is not possible - books, screencasts, articles + letters to those who write books, articles and write screencasts if something is not clear.
You will enjoy using TDD. It's really great to see a green bar after a red one. And it delays. Although you need to be careful and see the limits of applicability of this wonderful thing TDD.
If you do not understand the essence of the issue and rush headlong into TDD, you risk throwing away a lot of your time. And not every guide will tolerate it. First you need to learn how to write tests. And then go to TDD. Smoothly, without sudden movements. The brain switches itself at a certain moment.
TDD is cool, everyone writes about it, they talk more, let's be there. Radically wrong. Very close to an unprepared start - understand how it works, then begin.
With TDD you need to test the logic of the project. For everything else, there are other types of tests. And not all logic lends itself to this approach - an excellent example is described in the article Why unit tests do not work in scientific applications
We work primarily for customers. If in half an hour you have an important presentation and you urgently need to implement some new function, then you will not understand if you start writing a test and do not have time to write the implementation. You need to understand that sometimes TDD needs to be sacrificed for the sake of business challenges.
Test Driven Development: By Example
The first book should be the book of Kent Beck - it contains all the basics of TDD from the author of this approach. Required to read.
The Art of Unit Testing: With Examples in .Net
A book that will help you master the first skill - writing tests. About TDD there are just a couple of words. Examples in C #, but this is not essential - it will be useful to everyone. A good book review can be read here .
Refactoring: Improving the Design of Existing Code
Martin Faulerao's classic book refactoring, which helps you keep your code clean.
Refactoring To Patterns
Another book about refactoring. In it, Joshua Kirievski shows the connection of refactoring with design patterns. I recommend reading right after Fowler.
Working Effectively with Legacy Code
The book by Michael Fieters, which describes in detail how to work with inherited code. It is interesting how the author defines the very concept of “inherited code” - this is a code that is not covered by tests :) It will be very useful for those who work with such code.
I hope that you will write tests and use TDD, but only where it is really necessary. Take care of your feet.
The article was prepared based on my recent report at the .NET Developer Conference .
Recently, on Habré published quite a lot of articles on TDD, which cause mixed reactions from readers. There are more and more words, young developers reading these articles, wander in a haze of definitions and terms, somewhere in the subconscious mind realizing that TDD is probably great.
In this article I will try to explain what the conversation is about. What is TDD and how to use it carefully.
')
What is TDD in a nutshell? - This is the developer writing tests to implement the functionality.
On the advice of Roy Osherov, we divide the question of the applicability of TDD into two:
- Why write tests?
- Why write tests before implementation?
You test anyway
There is not a single sensible developer who would not check it before delivering the program to the client. What is there a developer, in any production, the product is tested at least visually. Take even aircraft construction, even weaving bast shoes - everywhere one way or another the product is checked. This applies to you and me. So if we test anyway, why not automate this process? Why, after each small change, manually check all the functionality, if you can do it with one click of a button?
Not everyone needs it.
In our projects of developers who do not write tests, we call ChakNorris, because they are incredibly cool and we sincerely envy them.
Why is Chuck not writing tests?
His code is perfect
In the code of Chuck Norris there are never bugs. He is never wrong. If you find a bug in Chuck's code - try to talk to him about it - you will immediately realize that this is actually a necessary feature of the project.
It does not need code documentation and project communication.
In fact, documentation is just one of the ways to communicate. Documenting the code, we communicate with the team (with the present and the future), which is working on the project. Tests are the best documentation. Developers do not read paper documentation at all, and these pieces of paper and files disappear all the time. In the written comments to the code, it is not always possible to figure out what exactly the author meant. In tests, you can immediately see how the code works, what they want to get from it.
Chuck doesn't need all this - he works alone.
Perfect memory
What projects can you work on alone? Only on those where you bought a plane ticket to a warm country in which the customer will not find you. On all other projects you work at least together - you and you in the future. And you need to communicate with yourself on the subject of implementation. Chuck is doing very well without it - he remembers everything in his projects.
Refactoring without problems
Chuck does not refactor at all, because his code is perfect at once. So there are no situations when you need to change or optimize something and try not to break anything in the process.
Why don't you write tests?
I do not understand what it is and why
A strange excuse, especially after you read why Chuck Norris does not write tests.
No time
With the help of tests you will save time. How much time do you spend now on debugging and manual testing of your applications? Yes, tests take time to write, but it pays off.
It is impossible to test
Almost everything can be tested, and what is impossible - it is not necessary. Mock frameworks are very helpful in this. Unit tests need to test logic in your project. Testing the interaction with the base, with external services and so on - this is already a conversation about integration and functional tests.
This is not my job
We have testers - let them test. The fewer bugs you leave to testers, the less you will work with them in the future. Work more efficiently - employers appreciate it.
I'm fine as it is
Congratulations, you are Chuck Norris.
Tests save time. Tests prevent the repetition of errors. With their help, the code is documented much more efficiently and you can feel much more comfortable during refactoring.
So why write them before implementation?
This picture and Kent Beck’s " Clean Code That Works " phrase is all about TDD. We want our code to work, and we want it to be clean. That's all. And with the help of the steps Red-> Green-> Refactoring, as practice shows, it is easier to achieve this.
At the Red stage, we write a test, evaluate the design of our function, right there we correct it. We are convinced that the functionality is not implemented and the test fails.
At the Green stage we reach the goal - “Code That Works” - our implementation starts working.
At the last stage of the Refactoring cycle, we realize the goal - “Clean Code” and it is still “That Works” ... and we go further.
The main idea of ​​TDD is not tests at all, it is a matter of design. When you write a test, you ask yourself what you want to do and how best to implement it. Here you test your design code, along with keeping the principles of Keep It Simple Stupid and You Ain't Gonna Need It .
What TDD gives is confidence. Are you sure that the test will be written - if you write tests after the functionality, then there are a thousand reasons not to do it. You are confident in your design. You are sure that everything you wanted is realized.
TDD is not a silver bullet
Unfortunately. There are no silver bullets at all, as Frederick Brooks wrote in his book . And TDD is no exception. You can still make mistakes, you can make mistakes in tests. Unit tests will not be limited to everything, you may need integration and other types of tests. TDD is definitely not enough to cover all your code. And most importantly - you will still need to think :) And do not relax.
How to start using TDD?
... described in TDD article - this is like snowboarding . In short - you need to be careful. You need to be aware of what you are doing and why. And the best option is to learn from someone who already uses this approach. If this is not possible - books, screencasts, articles + letters to those who write books, articles and write screencasts if something is not clear.
You will enjoy using TDD. It's really great to see a green bar after a red one. And it delays. Although you need to be careful and see the limits of applicability of this wonderful thing TDD.
Risk of being left out
Unprepared start
If you do not understand the essence of the issue and rush headlong into TDD, you risk throwing away a lot of your time. And not every guide will tolerate it. First you need to learn how to write tests. And then go to TDD. Smoothly, without sudden movements. The brain switches itself at a certain moment.
TDD for TDD
TDD is cool, everyone writes about it, they talk more, let's be there. Radically wrong. Very close to an unprepared start - understand how it works, then begin.
Going beyond the limits of applicability
With TDD you need to test the logic of the project. For everything else, there are other types of tests. And not all logic lends itself to this approach - an excellent example is described in the article Why unit tests do not work in scientific applications
Fanaticism
We work primarily for customers. If in half an hour you have an important presentation and you urgently need to implement some new function, then you will not understand if you start writing a test and do not have time to write the implementation. You need to understand that sometimes TDD needs to be sacrificed for the sake of business challenges.
What to read to start
Test Driven Development: By Example
The first book should be the book of Kent Beck - it contains all the basics of TDD from the author of this approach. Required to read.
The Art of Unit Testing: With Examples in .Net
A book that will help you master the first skill - writing tests. About TDD there are just a couple of words. Examples in C #, but this is not essential - it will be useful to everyone. A good book review can be read here .
Refactoring: Improving the Design of Existing Code
Martin Faulerao's classic book refactoring, which helps you keep your code clean.
Refactoring To Patterns
Another book about refactoring. In it, Joshua Kirievski shows the connection of refactoring with design patterns. I recommend reading right after Fowler.
Working Effectively with Legacy Code
The book by Michael Fieters, which describes in detail how to work with inherited code. It is interesting how the author defines the very concept of “inherited code” - this is a code that is not covered by tests :) It will be very useful for those who work with such code.
I hope that you will write tests and use TDD, but only where it is really necessary. Take care of your feet.
The article was prepared based on my recent report at the .NET Developer Conference .
Source: https://habr.com/ru/post/116514/
All Articles