December 13, 2012 at 22:25Test writing is not TDD!
- Transfer
This article is a good theoretical material on TDD for those who still do not know anything about it.
In the world of software development, there is a common misconception that simply writing tests is tantamount to developing through testing.
Development through testing (TDD) gives confidence that the program is operational at any given time and helps all its parts to be well-designed, reused, and loosely coupled.
In TDD, there are 3 basic rules from Uncle Bob :
The basic TDD follow-up process consists of 3 steps: red, green and refactoring .
The red stage consists of writing a test that fails. Only one test. If you can’t stop and continue to write a lot of tests, take the idea from the Getting Things Done and erase the extra thoughts from your head so that they do not distract you. There are several different ways you can use: create a to-do list on paper, draw an index card, add a series of TODO comments to your files, and many others. For myself, I determined that the physical action of deleting a fad on paper or drawing a checkmark and folding an index card in half gives me a greater sense of completion.
Your first test for a new facility should be simple. TDD focuses on emerging design - oppositesgreat design ahead . Let the design come from your code. The purpose of the first test is not functionality, but the definition of the boundaries of the use of what you are currently creating.
Start with the introduction: “What will I pass on to this action?” After that, think about the results: "What will this function return?" Write a guess, run the tests, and make sure your new test is red.
All other test cases at the red stage should focus on the developed functionality. Do not follow simple roads, think about the most unpredictable things you can do with a function or 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 fixing the one you just wrote, and then continue to fix the other red tests one at a time. Don't think about how your code looks or how efficient 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 phase 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 will fail if you make a mistake and lose working functionality.
Refactoring should only concern the restructuring of your code and giving it a more readable look. Do not forget to pay attention to improving tests, but do not refactor code and tests at the same time.
One of the advantages of TDD is the constant availability of correctly working code. You invest time in the performance of the code and you can always be sure that it works as intended.
TDD lets you not be afraid of change. I worked on many projects before I realized 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 disappeared - the functionality is always covered in tests, and you are able to get an almost instant response from the system or any part of it. At the same time, the absence of fear of refactoring increases the internal quality of your program, which has a positive effect on external quality.
TDD provides you with live code documentation. If you are the same as me, then the study of a new library starts not with fluffy documentation, but with examples of use. It is very important to understand and follow that when writing or refactoring tests, we must maintain their readability and simplicity of the algorithm. Unlike comments or lengthy documentation, tests are executable and always let you know when they lie.
I always worried that one of the D in TDD does not mean design. As I briefly mentioned earlier, the practice of TDD is not only writing tests in an attempt to make sure that the program is functional. TDD turns software development upside down and makes you think about the problem not from the inside, but from the outside.
Writing tests doesn't make you think about implementation — the main concern is using an object or function. Since we spend a lot 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, but you don’t know how to do it? How can you write a test first if you don’t know where to start? The answer is simple - but you can’t. 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 Rule No. 1 of the three rules of Uncle Bob. Work with it 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.
However, 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 these tests, you can quickly remember everything that you learned, and looking back, you will see great progress in your skills.
In the world of software development, there is a common misconception that simply writing tests is tantamount to developing through testing.
Development through testing (TDD) gives confidence that the program is operational at any given time and helps all its parts to be well-designed, reused, and loosely coupled.
What is TDD?
In TDD, there are 3 basic rules from Uncle Bob :
- Write only the code that is tested.
- Start writing small tests, and then build them up.
- Write as much code as you need to pass the test.
TDD Basics
The basic TDD follow-up process consists of 3 steps: red, green and refactoring .
Red
The red stage consists of writing a test that fails. Only one test. If you can’t stop and continue to write a lot of tests, take the idea from the Getting Things Done and erase the extra thoughts from your head so that they do not distract you. There are several different ways you can use: create a to-do list on paper, draw an index card, add a series of TODO comments to your files, and many others. For myself, I determined that the physical action of deleting a fad on paper or drawing a checkmark and folding an index card in half gives me a greater sense of completion.
Your first test for a new facility should be simple. TDD focuses on emerging design - oppositesgreat design ahead . Let the design come from your code. The purpose of the first test is not functionality, but the definition of the boundaries of the use of what you are currently creating.
Start with the introduction: “What will I pass on to this action?” After that, think about the results: "What will this function return?" Write a guess, run the tests, and make sure your new test is red.
All other test cases at the red stage should focus on the developed functionality. Do not follow simple roads, think about the most unpredictable things you can do with a function or 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 fixing the one you just wrote, and then continue to fix the other red tests one at a time. Don't think about how your code looks or how efficient 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 phase 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 will fail if you make a mistake and lose working functionality.
Refactoring should only concern the restructuring of your code and giving it a more readable look. Do not forget to pay attention to improving tests, but do not refactor code and tests at the same time.
Benefits of TDD
Working code
One of the advantages of TDD is the constant availability of correctly 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 lets you not be afraid of change. I worked on many projects before I realized 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 disappeared - the functionality is always covered in tests, and you are able to get an almost instant response from the system or any part of it. At the same time, the absence of fear of refactoring increases the internal quality of your program, which has a positive effect on external quality.
Live documentation
TDD provides you with live code documentation. If you are the same as me, then the study of a new library starts not with fluffy documentation, but with examples of use. It is very important to understand and follow that when writing or refactoring tests, we must maintain their readability and simplicity of the algorithm. Unlike comments or lengthy documentation, tests are executable and always let you know when they lie.
Architecture through code
I always worried that one of the D in TDD does not mean design. As I briefly mentioned earlier, the practice of TDD is not only writing tests in an attempt to make sure that the program is functional. TDD turns software development upside down and makes you think about the problem not from the inside, but from the outside.
Writing tests doesn't make you think about implementation — the main concern is using an object or function. Since we spend a lot 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, but you don’t know how to do it? How can you write a test first if you don’t know where to start? The answer is simple - but you can’t. 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 Rule No. 1 of the three rules of Uncle Bob. Work with it 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.
However, 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 these tests, you can quickly remember everything that you learned, and looking back, you will see great progress in your skills.