Extremely cool tester-style programming!
Have you, my dear, ever imagined a testing process going backwards? If yes, then you are already familiar with TDD!
Now we are going to talk about one of the methods of extreme programming and testing. But first - Toyota! Yes, yes, that same Toyota, a company that makes very good, as for me, cars. What they have to do with testing, the more extreme? Yes, the most immediate! And no, I do not mean software tests at a speed of 180 km / h. That would be stupid. Fun, but stupid.
TDD (Test-Driven Development) , or, in our opinion, development based on testing is quite an interesting technique, but as for me, TDD sounds cooler, and therefore I will call it that way here. We are cool, right?
')
So what am I talking about? Oh, Toyota! It is in this company that Taiichi Ohno developed TDD. This technique was originally focused on the production of cars. Taiichi was slightly obsessed with waste-free production and, in addition to everything, was smart enough to make the scrupulous Japanese dream come true. This is how TPS, the loving mom of TDD, appeared. His brilliant idea was to produce only the necessary number of auto parts needed for the first stages of assembly. Also, these parts were subject to extremely high quality requirements. The process of communication between the various stages of production was due to Kanban or, more simply, large boards with the necessary inscriptions and notes.
But this is a story about typewriters, what does this have to do with software testing? All the salt in eliminating waste (unnecessary effort in our case). This can be quite a critical factor for some projects. Let's fantasize and come up with a fairly everyday script. So, for clarity. You work by the sweat of your face, write the code, do not sleep at night, at lunch you see the code on the display of the microwave. And now comes the beautiful day. The code is added. But nobody uses it. Do not integrate your code for days or even weeks. And then, in a hurry and with crutches, they are driven into the program, so much so that he can no longer croak more. And when to check everything? When to have time to test performance? Again, sit at night at work and sleep only in their own imagination? Well, the code from the very beginning simply cannot be correct, as we all know from the notorious Murphy's law (in any code there is at least one bug, and even if there is only one line of code, there will be a bug in it).
Or the code can be written just for nothing. No, of course, when he wrote, the goal was, but then, due to various reasons, the need for it simply disappeared. It's a shame to tears. And time could be spent on something much more productive, right?
This is where TDD comes in. Using unit tests as your loyal Kanban, as a mighty morsenstern in the righteous struggle to reduce "waste in production." And most importantly - everything will be done on time and with timely feedback. Great bonus, as for me.
Although in theory, that is, in theory, everything sounds extremely simple. TDD seems extremely simple at first glance. At least by the fact that he has only two basic rules. What could be the rules of a wonderland, where the top is the bottom and the bottom is the top? Let's take a look:
Sounds easy, right? But these rules are easier to implement than follow them. These rules are simply trying to come up with the complications of the process just as much as possible. And a little more.
If you follow the rule number one (and we will follow it, because we are all certainly cool TDD-shnik with burning keyboards and other gadgets that add advantages to our heavenly coolness), then tests should be written before the code is written that needs to be tested . It seems to me that each of us was somewhat jealous of Yura Gagarin and would like to go to conquer the stars at least once in our life. Therefore, for our small example, we will use Java to measure the parameters of our potential explorer of the universe. Why? Because we can!
Don't be surprised by the fact that in the example there are only a few lines of testing code and not a single line of productive code. This is just an example, created for ease of perception. So what's all the same going on in it?
The initial test case for the class is doomed to be overwhelmed with the necessary number of explanations. Well, that only the first. Now you can begin to create a starship one point zero.
There are test cases and not the same as in the above example. Such cases in which the implementation is not always obvious. Then it is worth starting with a stub implementation, in which you will need to return the hard-coded code to its original value. Why do all this? Mainly because it will guarantee that we are testing the right thing. This is an important factor, because with the growth of the body it will be much more difficult to make sure that exactly what is needed is being tested.
But the study of alternatives is simplified. All because the altar of the great mega-code, which, in addition to its main function, destroys the undead and consecrates the house after the mother-in-law arrives, and also brews and pours beer, it was not a huge effort. And even psychologically, it's easier to pick up and erase these few scared lines of code. It's a pity of course, but not so much. Now you can safely run the test and enjoy, like a child, a green striped. Brutal and masculine rejoice and clap. After that, make every effort to find duplicate information and eliminate it. You can also see what can be improved.
What I do not like in the above example? Speed ​​dependent on state. There is also a complication, because the speed is in two places at once. Let's try to factor out here all with the means that the ' Driving Mode ' offers us.
After another run of the test and the confidence that my favorite, the colors of Alpine grass, the strip appears in Junit (which I used and forgot to mention, because the sclerosis was strong, I'm sorry). Now we have a little such and nice regression test.
These are such tiny repetitions and are the basis of TDD. Many walk too far. This is a very common mistake to take too big steps. But too small is not worth doing. Oh, gods of Olympus, how much I suffered, until I found the right balance. After all, if you do everything in very small portions, then the occupation in general loses its meaning. And if it is too fast, then all feedback is lost, all the data that help to do everything right. The whole point of TDD is lost, and the exercise becomes even less meaningful. But if the unit is as small as it is (oh, it sounded cool, even very), then the problem will be easy to find, and the feedback is adjusted, and in general the meadows are blooming, and unicorns will jump on them. Only balance can be found only based on personal experience, mountains of broken keyboards and peaks of eight-story Russian syllable.
What is another huge advantage of small steps? Do not go astray. After all, e-mails are constantly coming, calls are coming in, to which memes also need to be distracted sometimes. Or the worst of evils - a “beloved” colleague bangs on the keys as if they were beating a stake into their own black vampire heart. Distracts, right? But with a small CASIC it is quite easy to immediately return to the stormy stream of working life. This case is also great to complete a busy day and start it tomorrow with ease. Yes, and if he falls - not so offensive, he's tiny. But such a file provides a huge amount of, and immediately know what to grab.
Unfortunately, again, the right size is a private matter for everyone. The selection of such a segment should be based on experience, knowledge, and the level of beardiness, but how else?
How much will be up-front design? Who knows, this is just one of those questions that are not answered. It all depends on the project. We will continue to stick to the software for our ship. Suppose that among the security objectives, one of the techniques of behavior in non-standard situations was written by two different teams. Both teams were engaged in writing programs that should work in parallel. The programs will be given certain parameters, and if they somehow disagree, then, say, the launch is canceled automatically. This separation technique shows that the up-front in this case are two different software programs that will need to agree with each other, and this effect is difficult to achieve from one program.
Many people ask this question, and I used to get lost, what to answer? Well, what code do you sculpt when programming? How do you know what to create? Should unit tests be tied to requirements? TDD confidently replies that it does not.
The whole point of the question is that the demands come from a terrible realm of potential problems. And we, my friends, the researchers, are trying to moor at the tender shores of answers and fixes, fertile shores, full of young maidens and other joys.
TDD offers to bake about the details, but not too get involved. Their number should try to reduce. In other words, write your unit tests in the same language as the Code itself (the one with a capital letter, the most important one).
What is TDD? I would prefer to think of it as a design technique, first and foremost. That is, of course, the developers of unit tests serve the vital goal of verification. But you must agree that they verify the correctness of the code. Thus, every little bit self-respecting project will force them to the acceptance and requirements tests. Unit tests are simply a strong foundation that is necessary for the proper functioning of the whole. This is how TDD allows you to focus on the important, which leads to overall success, joy and a lot of money. Paradise, whatever you say.
Another very nice feature of TDD is that it is in itself an excellent tool for verifying a target. With TDD, the target must be specified twice: both in unit tests and in the code itself. And only if they harmoniously fit each other, you can enjoy the green line.
Code coverage is an extremely useful technique. It is used to obtain additional information through feedback. Information about the quality of unit tests. It is necessary to place the analysis system itself in the build. Thus, the unit test can be run, and the report itself can be obtained with just one command. But the analysis should not get carried away at least until at least one version of any module is complete.
It's nice that TDD will give you 100% of the data (in theory) due to the fact that you have not yet written the code, following the rule number one, exactly until the cars failed you.
Embracing code is what you need to get more information and help fix broken windows.
To begin with, I would like to note that I do not mean any operating system at all. Broken windows and at the entrance may be. We will talk about them. There is such an interesting experiment in psychology. If you break one window in a house and do not repair it, then eventually all windows will be broken in the house.
And here is IT? It seems to me that you already guess where I am leading all this. A class without unit tests can be called a broken window. All he does in the end is to throw up extra reasons for not doing unit tests. And things get worse and worse.
The window will be difficult to repair, since the code was not written in the same language as the tests (most likely).
What will be waiting for you on the other side of the right TDD-Schnick, except for tea and cookies? Opportunities for expansion and "zhukokou" for the program, which already exists. Since it was originally written in the language of tests. And therefore you can just continue to write the necessary tests, drinking hot seagulls / coffee / beer / birch fresh and smoking bamboo. You know the value of the whole window, if you wish, it will be possible to slightly spice up this matter with regression, and here it is - happiness. Yes, and it will be very noticeable if the code is written and not previously tested. The window will break with a ring, it is difficult not to notice.
Oh, God, how painful it is to constantly patch software, look after it after release and so on and so forth. But TDD can make this process much less painful. Thanks to all these small and lightning interactions, the software is ready for content right from the start. Yes, and it says everything is convenient for the extermination of beetles.
So how do you make successful modifications? TDD allows you to just follow your course. That is, just do not change the unit tests and units that are currently being tested at the same time. Let alternate if you need to change something. The correct flow of events is as follows:
TDD - something extremely strict, but from all that is strict, it is easy to slip. And therefore there is a list of things that should be overdue, if you want to be a hard-working TDD-schnick.
Of course, TDD is not a panacea, and this technique cannot be applied to everything that hurts. And of course, it does not expose other vehicles in a bad light. TDD is just there for you, if it suits you - use it. However, TDD is definitely better than running around crazy and waving hands, firing shots from shotguns and rocket launchers hours before release. But I would not call this funny process a technique. For me, this is just an unscheduled action that carries only entertainment purposes.
What TDD actually does is reverse the testing and development processes. At the same time finding a middle ground for high-quality design and excellent awareness in the process. But do not forget (NEVER) that TDD requires discipline and dedication.
But, as in any situation in life, the choice is yours, friends. I would just like to wish you good luck in all your endeavors, and the customer will not hurt you, the crutch put out will not be knocked out, but the whole process will not go to hell because of the unpleasant little things! All the rays of good!
Little history
Now we are going to talk about one of the methods of extreme programming and testing. But first - Toyota! Yes, yes, that same Toyota, a company that makes very good, as for me, cars. What they have to do with testing, the more extreme? Yes, the most immediate! And no, I do not mean software tests at a speed of 180 km / h. That would be stupid. Fun, but stupid.
TDD (Test-Driven Development) , or, in our opinion, development based on testing is quite an interesting technique, but as for me, TDD sounds cooler, and therefore I will call it that way here. We are cool, right?
')
So what am I talking about? Oh, Toyota! It is in this company that Taiichi Ohno developed TDD. This technique was originally focused on the production of cars. Taiichi was slightly obsessed with waste-free production and, in addition to everything, was smart enough to make the scrupulous Japanese dream come true. This is how TPS, the loving mom of TDD, appeared. His brilliant idea was to produce only the necessary number of auto parts needed for the first stages of assembly. Also, these parts were subject to extremely high quality requirements. The process of communication between the various stages of production was due to Kanban or, more simply, large boards with the necessary inscriptions and notes.
But this is a story about typewriters, what does this have to do with software testing? All the salt in eliminating waste (unnecessary effort in our case). This can be quite a critical factor for some projects. Let's fantasize and come up with a fairly everyday script. So, for clarity. You work by the sweat of your face, write the code, do not sleep at night, at lunch you see the code on the display of the microwave. And now comes the beautiful day. The code is added. But nobody uses it. Do not integrate your code for days or even weeks. And then, in a hurry and with crutches, they are driven into the program, so much so that he can no longer croak more. And when to check everything? When to have time to test performance? Again, sit at night at work and sleep only in their own imagination? Well, the code from the very beginning simply cannot be correct, as we all know from the notorious Murphy's law (in any code there is at least one bug, and even if there is only one line of code, there will be a bug in it).
Or the code can be written just for nothing. No, of course, when he wrote, the goal was, but then, due to various reasons, the need for it simply disappeared. It's a shame to tears. And time could be spent on something much more productive, right?
This is where TDD comes in. Using unit tests as your loyal Kanban, as a mighty morsenstern in the righteous struggle to reduce "waste in production." And most importantly - everything will be done on time and with timely feedback. Great bonus, as for me.
It's hard to learn ...
Although in theory, that is, in theory, everything sounds extremely simple. TDD seems extremely simple at first glance. At least by the fact that he has only two basic rules. What could be the rules of a wonderland, where the top is the bottom and the bottom is the top? Let's take a look:
- Forget about writing new code. Stop it. Get away from the keyboard at a safe distance and fight with all your strength. At least until automation fails you.
- Do not repeat. Eliminate everything that duplicates each other.
Sounds easy, right? But these rules are easier to implement than follow them. These rules are simply trying to come up with the complications of the process just as much as possible. And a little more.
If you follow the rule number one (and we will follow it, because we are all certainly cool TDD-shnik with burning keyboards and other gadgets that add advantages to our heavenly coolness), then tests should be written before the code is written that needs to be tested . It seems to me that each of us was somewhat jealous of Yura Gagarin and would like to go to conquer the stars at least once in our life. Therefore, for our small example, we will use Java to measure the parameters of our potential explorer of the universe. Why? Because we can!
Don't be surprised by the fact that in the example there are only a few lines of testing code and not a single line of productive code. This is just an example, created for ease of perception. So what's all the same going on in it?
- Creating an object. Our spaceship was successfully created. And in the normal state it does not move. Accordingly, its speed is 0 miles per second. This is not the most accurate definition of a starship, but, first, I am not a developer of spacecraft, and secondly, for our purposes, as is customary in Russia, and so it will come down. We need to deal with each problem in turn, or, as our TDD colleagues call it, to deal with organic design.
- API design. Unit tests are most fortunate. They will be the first to try out bits of code on themselves. And, accordingly, they will be the first to provide us with the necessary data. The point is that we will receive the data before writing this code. Cool, right?
- Decapling At the moment, the class of the spacecraft is decal (separated) from certain models of motion. All that he still knows is the interface ' Driving Mode ' in which we can see the standard TDD template. The string containing the design principles is programmed for the interface, not for the implementation. The great advantage is that now we are subject to the unit, which is tested by stub (simulation of the behavior of the software component). I would also try not to rely too much on specific classes. They usually add at least one inaccuracy of factors. And more than one inaccuracy is not something that is easy to handle in TDD.
- Side effects. What will change the movement pattern mean? Only that it will now be equal to the highest speed of a particular model, as indicated in the example.
The initial test case for the class is doomed to be overwhelmed with the necessary number of explanations. Well, that only the first. Now you can begin to create a starship one point zero.
There are test cases and not the same as in the above example. Such cases in which the implementation is not always obvious. Then it is worth starting with a stub implementation, in which you will need to return the hard-coded code to its original value. Why do all this? Mainly because it will guarantee that we are testing the right thing. This is an important factor, because with the growth of the body it will be much more difficult to make sure that exactly what is needed is being tested.
But the study of alternatives is simplified. All because the altar of the great mega-code, which, in addition to its main function, destroys the undead and consecrates the house after the mother-in-law arrives, and also brews and pours beer, it was not a huge effort. And even psychologically, it's easier to pick up and erase these few scared lines of code. It's a pity of course, but not so much. Now you can safely run the test and enjoy, like a child, a green striped. Brutal and masculine rejoice and clap. After that, make every effort to find duplicate information and eliminate it. You can also see what can be improved.
What I do not like in the above example? Speed ​​dependent on state. There is also a complication, because the speed is in two places at once. Let's try to factor out here all with the means that the ' Driving Mode ' offers us.
After another run of the test and the confidence that my favorite, the colors of Alpine grass, the strip appears in Junit (which I used and forgot to mention, because the sclerosis was strong, I'm sorry). Now we have a little such and nice regression test.
After flushing - repeat, as the good old bearded anecdote says
These are such tiny repetitions and are the basis of TDD. Many walk too far. This is a very common mistake to take too big steps. But too small is not worth doing. Oh, gods of Olympus, how much I suffered, until I found the right balance. After all, if you do everything in very small portions, then the occupation in general loses its meaning. And if it is too fast, then all feedback is lost, all the data that help to do everything right. The whole point of TDD is lost, and the exercise becomes even less meaningful. But if the unit is as small as it is (oh, it sounded cool, even very), then the problem will be easy to find, and the feedback is adjusted, and in general the meadows are blooming, and unicorns will jump on them. Only balance can be found only based on personal experience, mountains of broken keyboards and peaks of eight-story Russian syllable.
What is another huge advantage of small steps? Do not go astray. After all, e-mails are constantly coming, calls are coming in, to which memes also need to be distracted sometimes. Or the worst of evils - a “beloved” colleague bangs on the keys as if they were beating a stake into their own black vampire heart. Distracts, right? But with a small CASIC it is quite easy to immediately return to the stormy stream of working life. This case is also great to complete a busy day and start it tomorrow with ease. Yes, and if he falls - not so offensive, he's tiny. But such a file provides a huge amount of, and immediately know what to grab.
Unfortunately, again, the right size is a private matter for everyone. The selection of such a segment should be based on experience, knowledge, and the level of beardiness, but how else?
Different levels of design
How much will be up-front design? Who knows, this is just one of those questions that are not answered. It all depends on the project. We will continue to stick to the software for our ship. Suppose that among the security objectives, one of the techniques of behavior in non-standard situations was written by two different teams. Both teams were engaged in writing programs that should work in parallel. The programs will be given certain parameters, and if they somehow disagree, then, say, the launch is canceled automatically. This separation technique shows that the up-front in this case are two different software programs that will need to agree with each other, and this effect is difficult to achieve from one program.
And what tests should I write if I don't know the requirements?
Many people ask this question, and I used to get lost, what to answer? Well, what code do you sculpt when programming? How do you know what to create? Should unit tests be tied to requirements? TDD confidently replies that it does not.
The whole point of the question is that the demands come from a terrible realm of potential problems. And we, my friends, the researchers, are trying to moor at the tender shores of answers and fixes, fertile shores, full of young maidens and other joys.
TDD offers to bake about the details, but not too get involved. Their number should try to reduce. In other words, write your unit tests in the same language as the Code itself (the one with a capital letter, the most important one).
Why all these overseas TDDs?
What is TDD? I would prefer to think of it as a design technique, first and foremost. That is, of course, the developers of unit tests serve the vital goal of verification. But you must agree that they verify the correctness of the code. Thus, every little bit self-respecting project will force them to the acceptance and requirements tests. Unit tests are simply a strong foundation that is necessary for the proper functioning of the whole. This is how TDD allows you to focus on the important, which leads to overall success, joy and a lot of money. Paradise, whatever you say.
Another very nice feature of TDD is that it is in itself an excellent tool for verifying a target. With TDD, the target must be specified twice: both in unit tests and in the code itself. And only if they harmoniously fit each other, you can enjoy the green line.
Covering code
Code coverage is an extremely useful technique. It is used to obtain additional information through feedback. Information about the quality of unit tests. It is necessary to place the analysis system itself in the build. Thus, the unit test can be run, and the report itself can be obtained with just one command. But the analysis should not get carried away at least until at least one version of any module is complete.
It's nice that TDD will give you 100% of the data (in theory) due to the fact that you have not yet written the code, following the rule number one, exactly until the cars failed you.
Embracing code is what you need to get more information and help fix broken windows.
Broken windows
To begin with, I would like to note that I do not mean any operating system at all. Broken windows and at the entrance may be. We will talk about them. There is such an interesting experiment in psychology. If you break one window in a house and do not repair it, then eventually all windows will be broken in the house.
And here is IT? It seems to me that you already guess where I am leading all this. A class without unit tests can be called a broken window. All he does in the end is to throw up extra reasons for not doing unit tests. And things get worse and worse.
The window will be difficult to repair, since the code was not written in the same language as the tests (most likely).
What will be waiting for you on the other side of the right TDD-Schnick, except for tea and cookies? Opportunities for expansion and "zhukokou" for the program, which already exists. Since it was originally written in the language of tests. And therefore you can just continue to write the necessary tests, drinking hot seagulls / coffee / beer / birch fresh and smoking bamboo. You know the value of the whole window, if you wish, it will be possible to slightly spice up this matter with regression, and here it is - happiness. Yes, and it will be very noticeable if the code is written and not previously tested. The window will break with a ring, it is difficult not to notice.
Caring for software
Oh, God, how painful it is to constantly patch software, look after it after release and so on and so forth. But TDD can make this process much less painful. Thanks to all these small and lightning interactions, the software is ready for content right from the start. Yes, and it says everything is convenient for the extermination of beetles.
So how do you make successful modifications? TDD allows you to just follow your course. That is, just do not change the unit tests and units that are currently being tested at the same time. Let alternate if you need to change something. The correct flow of events is as follows:
- Analyze the necessary changes
- Run unit tests
- Write more of these
- Understand what needs to be changed. Follow the TDD procedure you are used to.
- Victory!
TDD Recommendations
TDD - something extremely strict, but from all that is strict, it is easy to slip. And therefore there is a list of things that should be overdue, if you want to be a hard-working TDD-schnick.
- The unit code and the code that is being tested should be equivalent.
- Unit tests should be as small and independent as, say, Monaco.
- Use permanent names. The ones you are used to. Thus, navigation is greatly simplified. Call the unit tests according to the units being tested.
What have we learned?
Of course, TDD is not a panacea, and this technique cannot be applied to everything that hurts. And of course, it does not expose other vehicles in a bad light. TDD is just there for you, if it suits you - use it. However, TDD is definitely better than running around crazy and waving hands, firing shots from shotguns and rocket launchers hours before release. But I would not call this funny process a technique. For me, this is just an unscheduled action that carries only entertainment purposes.
What TDD actually does is reverse the testing and development processes. At the same time finding a middle ground for high-quality design and excellent awareness in the process. But do not forget (NEVER) that TDD requires discipline and dedication.
But, as in any situation in life, the choice is yours, friends. I would just like to wish you good luck in all your endeavors, and the customer will not hurt you, the crutch put out will not be knocked out, but the whole process will not go to hell because of the unpleasant little things! All the rays of good!
Source: https://habr.com/ru/post/234749/
All Articles