Simply writing tests is not TDD!
This article is a good theoretical material about TDD for those who still do not know about it.
In the software development world, there is a common misconception that simply writing tests is tantamount to developing through testing.
')
Development through testing (TDD) gives confidence in the program's performance at any given time and helps all its parts to be well designed, reused and weakly connected.
In TDD, there are 3 basic rules from Uncle Bob :
The basic TDD follow process consists of 3 steps: red, green, and refactoring .
The red stage consists of writing a test that is not passed. Only one test. If you can’t stop and continue to write a lot of tests, borrow an idea from Getting Things Done and get the extra thoughts out of your head so they don’t distract you. There are several different ways you can use: create a list of upcoming cases on paper, draw an index map, add a TODO series of comments to your files and many others. For myself, I determined that the physical action of crossing out a fad on paper or drawing a tick and folding the index card in half gives me a greater sense of completeness.
Your first test for a new object should be simple. TDD focuses on emerging engineering — the opposite of big design ahead . Let the design come from your code. The purpose of the first test is not functionality, but the definition of the limits of use of what you are creating now.
Start with introductory words: “What will I pass on to this action?”. After that, think about the results: “What will this function return?”. Write an assumption, run the tests and make sure that your newly appeared test is red.
All other test cases in the red stage should focus on the developed functionality. Do not go by simple roads, think about the most unpredictable things you can do with a function or an object. What happens if you pass the null parameter? What happens when I pass a negative number? What about passing a string when the code expects to see a number?
The green stage is to pass the falling tests as soon as possible. If more than one test fails, start by correcting the one you just wrote, and then continue to correct the other red tests one by one. Do not think about how your code looks or how effective it is. Your goal should be to pass the test so that you can make sure that another part of the functionality is covered by tests.
The next step is refactoring, restructuring and organizing your code. The refactoring step can occur at any time: after 1 red / green cycle, after four or more. Since you have at least 1 green test, you can rewrite the code with ease and comfort, knowing that your tests fail, if you make a mistake and lose the working functionality.
Refactoring should relate only to restructuring your code and making it more readable. Do not forget to pay attention to the improvement of tests, but do not do refactoring of code and tests at the same time.
One of the advantages of TDD is the constant availability of properly working code. You invest time in the performance of the code and you can always be sure that it works as intended.
TDD allows you to not be afraid of change. I worked in a lot of projects before I felt the benefits of TDD. Looking back, I can say that I was always afraid to make changes to the code. I spent a lot of time testing the application manually in order to make sure that I did not break its performance. With the advent of TDD, this fear is gone - the functionality is always covered with tests, and you are able to get an almost instant response from the system or any part of it. At the same time, the lack of fear of refactoring increases the internal quality of your program, which positively affects the external quality.
TDD provides you with live code documentation. If you are the same as me, the study of a new library does not begin with fluffy documentation, but with examples of use. It is very important to understand and follow the fact that when writing or refactoring tests, we must preserve their readability and simplicity of the algorithm. Unlike comments or long documentation, tests are executable and always tell you when they lie.
I have always worried that one of D in TDD does not mean design. As I briefly mentioned earlier, TDD practice is not just writing tests in an attempt to make sure that the program is working. TDD turns program development upside down and makes you think about the problem not from the inside, but from the outside.
Writing tests makes you not thinking about implementation - the main concern is with the use of an object or function. Since we spend a large amount of time directly interacting with the objects and functions that we write, the architecture manifests itself from the code itself.
What if you need to use a new library or framework, and you don't know how to do this? How can you write a test in the first place, if you do not know where to start? The answer is simple - and you can not. Create a new project and use the new library separately from your working code. Such new projects are called crutches . Since they are not in your working code, you do not violate Uncle Bob's Rule # 1 of the three rules. Work with him until you feel comfortable using this library. When you find out how your library works, forget the crutches and go back to your working code and start by writing tests.
Anyway, if you can't use TDD, don't forget about the importance of writing tests. Your tests will serve as a reference for you and (if your crutch is in the version control system) for those who come after you. With the help of these tests, you can quickly remember everything that you have learned, and, looking back, you will see great progress in your mastery.
In the software development world, there is a common misconception that simply writing tests is tantamount to developing through testing.
')
Development through testing (TDD) gives confidence in the program's performance at any given time and helps all its parts to be well designed, reused and weakly connected.
What is TDD?
In TDD, there are 3 basic rules from Uncle Bob :
- Write only the code that is tested.
- Start writing tests with small, and then build them up.
- Write as much code as you need to pass the test.
TDD basics
The basic TDD follow process consists of 3 steps: red, green, and refactoring .
Red
The red stage consists of writing a test that is not passed. Only one test. If you can’t stop and continue to write a lot of tests, borrow an idea from Getting Things Done and get the extra thoughts out of your head so they don’t distract you. There are several different ways you can use: create a list of upcoming cases on paper, draw an index map, add a TODO series of comments to your files and many others. For myself, I determined that the physical action of crossing out a fad on paper or drawing a tick and folding the index card in half gives me a greater sense of completeness.
Your first test for a new object should be simple. TDD focuses on emerging engineering — the opposite of big design ahead . Let the design come from your code. The purpose of the first test is not functionality, but the definition of the limits of use of what you are creating now.
Start with introductory words: “What will I pass on to this action?”. After that, think about the results: “What will this function return?”. Write an assumption, run the tests and make sure that your newly appeared test is red.
All other test cases in the red stage should focus on the developed functionality. Do not go by simple roads, think about the most unpredictable things you can do with a function or an object. What happens if you pass the null parameter? What happens when I pass a negative number? What about passing a string when the code expects to see a number?
Green
The green stage is to pass the falling tests as soon as possible. If more than one test fails, start by correcting the one you just wrote, and then continue to correct the other red tests one by one. Do not think about how your code looks or how effective it is. Your goal should be to pass the test so that you can make sure that another part of the functionality is covered by tests.
Refactoring
The next step is refactoring, restructuring and organizing your code. The refactoring step can occur at any time: after 1 red / green cycle, after four or more. Since you have at least 1 green test, you can rewrite the code with ease and comfort, knowing that your tests fail, if you make a mistake and lose the working functionality.
Refactoring should relate only to restructuring your code and making it more readable. Do not forget to pay attention to the improvement of tests, but do not do refactoring of code and tests at the same time.
TDD benefits
Working code
One of the advantages of TDD is the constant availability of properly working code. You invest time in the performance of the code and you can always be sure that it works as intended.
Change without fear
TDD allows you to not be afraid of change. I worked in a lot of projects before I felt the benefits of TDD. Looking back, I can say that I was always afraid to make changes to the code. I spent a lot of time testing the application manually in order to make sure that I did not break its performance. With the advent of TDD, this fear is gone - the functionality is always covered with tests, and you are able to get an almost instant response from the system or any part of it. At the same time, the lack of fear of refactoring increases the internal quality of your program, which positively affects the external quality.
Live Documentation
TDD provides you with live code documentation. If you are the same as me, the study of a new library does not begin with fluffy documentation, but with examples of use. It is very important to understand and follow the fact that when writing or refactoring tests, we must preserve their readability and simplicity of the algorithm. Unlike comments or long documentation, tests are executable and always tell you when they lie.
Architecture through code
I have always worried that one of D in TDD does not mean design. As I briefly mentioned earlier, TDD practice is not just writing tests in an attempt to make sure that the program is working. TDD turns program development upside down and makes you think about the problem not from the inside, but from the outside.
Writing tests makes you not thinking about implementation - the main concern is with the use of an object or function. Since we spend a large amount of time directly interacting with the objects and functions that we write, the architecture manifests itself from the code itself.
When not TDD
What if you need to use a new library or framework, and you don't know how to do this? How can you write a test in the first place, if you do not know where to start? The answer is simple - and you can not. Create a new project and use the new library separately from your working code. Such new projects are called crutches . Since they are not in your working code, you do not violate Uncle Bob's Rule # 1 of the three rules. Work with him until you feel comfortable using this library. When you find out how your library works, forget the crutches and go back to your working code and start by writing tests.
Anyway, if you can't use TDD, don't forget about the importance of writing tests. Your tests will serve as a reference for you and (if your crutch is in the version control system) for those who come after you. With the help of these tests, you can quickly remember everything that you have learned, and, looking back, you will see great progress in your mastery.
Source: https://habr.com/ru/post/162417/
All Articles