Test-driven development - cart or horse?
Test Driven Development (TDD) is undeniably an outstanding technique, giving a number of advantages. Application developers, and regardless of the scale of the project and the number of specialists involved, are not widely followed by TDD. But there are ardent supporters of this approach, moreover, they are ready to appeal not only to common sense or production necessity, but also to unconditionally successful examples of its implementation. One of these apologists is Alexander Lyulin , who not only talks about the degree of positive impact of TDD on development, but also shares the expertise of the implementation and rigorous everyday use of this technique, down to the source codes and script examples (in his blog ). However, the main brake on the road to the principles of TDD is, predictably, a set of purely psychological attitudes. In the “hard talk” mode, we will communicate with Alexander about the need for Test Driven Development.
Test Driven Development - an attempt to follow the fashion? Blindly copying other people's approaches?
Let's "immediately determine." I do not use TDD in its classic sense. And do not quote here "Wikipedia"! In general, it is unlikely that someone from professionals considers encyclopedic articles as a guide to action. We “suffered” our approach as part of a successful project, so we have real experience, not “stupid use of other people's ideas.” Rather, we use synthesis from TDD and our own ideas about how to develop software. Even if these “external ideas” come from very smart people, they should be critically interpreted and adapted to the real company, the existing team and the strategy of development and quality assurance. But I will continue to say "TDD", referring to the process of "developing through testing", which closely correlates with the encyclopedic Test Driven Development, but goes much further than it.
')
TDD is an attempt to turn everything upside down. In the engineering classics, an installation / technical system / machine / unit is first created. Of course, the test method is meant when designing ... but still, programmers are some special kind of engineers? Genetically flawed? Do not you consider yourself so?
It all depends on the definition - that "head", and that "legs." And as you know, the most scientific debate is a debate about terms. If we talk about the test procedure as a self-sufficient and deeply developed discipline, then we can not say that it is on an industrial scale. Then she would de facto be present everywhere and there would be no controversy in principle. But this, in fact, does not distinguish us fundamentally from other engineers who, for example, make coffee makers, lawn mowers or bicycles (not to be confused with “bicycles”).
Do I consider myself "genetically flawed"? By virtue of the profession, in part, yes. Therefore, I strive with all my strength to become better. Software development is an engineering craft, so you don’t have to suddenly consider yourself a superman or some creator. We are artisans (with the exception of units), this must be realized and reconciled. And try to become a normal (and not a genetically detrimental) engineer - tolerances, drawings, test methods, etc.
TDD - constrains developer initiative. It is no longer the developer himself who controls the process, but the task “falls on him with snowballs”? Is there any psychological discomfort? The programmer is no longer a creator, but a thoughtless machine of how to implement the functionality?
On the contrary, TDD does not constrain anything, but allows you to work more productively. Of course, “productively” means “working more.” Instead of one class, you have to write two: the projected class itself and the test for it. TDD is just for enterprising people. Who love their work. If there is a desire to optimize (= save your work time), then it is already at the door with the inscription "for idlers". Potential idlers or people practicing idleness during working hours may no longer read.
Only no one controls the developer, he controls himself - "beats his hands." But this is not masochism. Instead, the developer gets something important - a sense of stability and confidence in their professional tomorrow. And as a creator - he creates twice as much. It is creating, not "plowing." He just plows less. I am waiting for the next question for clarification.
TDD - puts at the forefront not the quality of implementation, but momentary features. How can you talk about code quality? About system architecture? From the point of view of the program code, we get “olivier salad” - a mechanical mixture of finely sliced ​​pieces of different flavor and color? Do you believe that from a vinaigrette, folded in a large group can symbolize an architecturally perfect and constructive quality?
This is absolutely not true. It is quality and stability that is put at the forefront. Just, there is a “feature” - there is a test confirming that this is a “feature” and not a “bug”. What did not fall into the TZ, then did not fall into the tests, whence then will it take in the functional? Only this way: the customer’s desire is expressed in the TZ, from there it flows into the tests, and only then the functionality appears.
Now, about architecture ... Architecture is not something universal and self-valuable. And do not have a silver bullet. And not what a bad bullet is made of. I know the architecture of the system, because I have been doing it for 15 years and I know it very well, thanks to the UML drawings. I have a complete set of design solutions in the form of UML diagrams. But here there is a chance not to keep everything in memory. How to restore all this in memory? Just look at a specific test.
Tests are “archived memory”, as well as “documentation” and “use cases”.
In this case, the tests are more stable and invariant compared to the project code. The code is reborn. Evolving. Dies. With tests, this happens much less frequently. You see, there is no conflict of interest between the architecture and the tests. And they are in their bundle more important than the code.
TDD - a scourge that whipped disobedient IT-slaves? Is this some kind of "council" for freedom-loving people, proudly referred to as "developers"? You, developers, should not think. Your job is to pull the strap, to fulfill the plan for the shaft! Look at the tests given by you from above, and do not even dare to take the initiative!
So this means ... “Management”, (to the Directorate and especially customers) really doesn’t matter what technologies are used (with rare exceptions, which we will not hope for). In general, no one soars, and what's "inside" the developers do? They use RUP, TDD / ShmeDD, Agile / SuperAgile or something else ...
All the above listed “stakeholders” - the result is important, not the process. No sensible boss will impose TDD. He needs the result, not the irritation of the developers - “this clever man again imposes some newfangled pieces on us”. A smart boss ... really smart (in IT it is more often than in other areas) can only make the developers feel the need themselves. This is the only way, otherwise it is a dead end.
There are no tests given above. Tests are an internal matter for developers. And the better the tests and the more of them, the developers “sleep better”. And the less they are called on the carpet. Tests - for developers, not for chiefs.
TDD is an attempt by incompetent and far from coding people to promote their ideology alien to developers ... their own, often wrong vision of the product development strategy.
Again. Tests are not dictated by the “directorate”, the management or the customers. Tests are a development tool. Tests are the “internal kitchen” of developers and quality groups. All other "stakeholders" operate TK. Well, or "screens." Maximum ... Tests and "development strategy" do not correlate at all.
Suppose I was obliged to follow the TDD technique, although, you see, many people feel comfortable without it. Well, what does this give in comparison with normal technology, when “we planned - implemented - did tests - tested”? Just a “beautiful fairy tale” for the boss “are we using cutting-edge approaches?”
You can be such a stubborn opponent of TDD! "Require" to use tests impossible. You can only persuade. If someone feels comfortable without tests, it means that:
- his project is not so complicated;
- it tests everything on real users (they are not lucky)
- He is a genius;
- he works alone.
Let's look in the mirror and choose our category.
Once again: “Fairy tales” - no, the administration doesn’t care, it needs a result, time and quality.
I plowed tests. Began under them (reluctantly) customized functional code. It turns out ... then that the test was invented incorrectly. I wasted for nothing?
Here "plow" nothing. One feature - one test. Iteratively. A feature spawns a test, and a test spawns a feature. XP, kiss-principle.
And there is no such thing that the “tests”, which acquired the form of a “hard task,” began to contradict each other?
This is my favorite question from the category of "brilliant"! If tests contradict each other, then:
- TK is not well developed;
- TK is contradictory.
Then you need to say "thank you" to the tests and return to the elaboration of the TK
TDD is a waste of time. Let's first write the code, and then we will test it. Any walking backwards, an unnatural order of development, even if it does not affect the quality, will necessarily cause a brake.
Is logical. So many do. Let's write the code. We will write. Let's fix it in CVS / SVN. So what? Have we done our job? Type "how lucky"? To ride / not to ride? Could be so. Only then will they “raise you out of bed” and ask “what the hell are you writing here?” So?
You can in another way - write the code and check it. And how are we going to check it? Stupid poking?
And if for “poking” you need to take 20 steps? And if 100? And if "no data"? And if "subcontractors are not ready"? Isn't it easier to “write a test” at least for debugging? With invented "from the head" input and output. In my opinion, easier. And if the test is ALREADY written and used for debugging, then why not include this test in the "nightly build"?
TDD - a way to put a developer in a demeaning position. "Broken unbeaten luck." The programmer works “from the feeling of guilt” in the permanent state of non-realization of the task.
On the contrary, the programmer has always “fixed points”. Here I wrote a test. He does not pass. Here I implemented the functionality. The test began to pass.
I did everything in CVS / SVN. I have done my work and “can sleep well”.
TDD - is there a feeling that the programmer is solving the inverse problem all the time? Or is the developer a Loser, customizing the solution to the answer of the problem?
And programmers always solve the inverse problem. Well, or "build a spherical horse in a vacuum." A programmer is not a loner, but an ordinary person who cannot foresee everything. But what he provided for is guaranteed to work. There are other people. But they are geniuses, but they are few.
TDD - development in the looking glass. We performed tests that are not a guarantee of infallibility. Who is responsible for the quality of the tests?
There is no guarantee of complete infallibility. There is only a guarantee that the developer correctly understood the TK and implemented it as it understood it.
TDD - a cart in front of the horse. The horse constantly pokes its muzzle “into the rear bumper”, not seeing anything ahead of itself. How can you talk about thinking through the functional as a whole at the level of the system architecture, when ahead - far into the horizon - just a dump of needs?
Here again, let's go back to the "most scientific dispute." We define the terms that is a cart and what is a horse. And I do not need to threaten Wikipedia (how can I test what is not)?
So it will be right:
- “horse” is TK;
- “cart” is CODE.
And what are the tests? Tests are “shafts” with which the horse is tied to a cart. The whole process of TZ is lucky, and the tests pull the code behind them and check its compliance with the TZ. The code goes in the same direction as the TK. There is no TestFirst! Neither CodeFirst! There are TK-first. But this is if simplified. The chain looks like this: TK -> Architecture Sketch -> Test -> Code, and then options are possible.
TK -> Architecture Sketch -> Test -> Code -> Test -> Code
TK -> Architecture Sketch -> Test -> Code -> Architecture -> Test -> Code
TK -> Architecture Sketch -> Test -> Code -> Architecture -> Test -> Code -> TK -> Architecture -> Test -> Code
…etc. etc.
First: TK and architecture sketch, then the iterative development begins.
And what is especially tasty, that as soon as we wrote a test, we do not need to think, but where to check the performance of our class? We have already configured the entire infrastructure for its testing and verification. This is what the word Driven in TDD means.
Well, there are "perverts" in the world. Then how can you alleviate the suffering? What is the correct process for this?
No, well, thanks for the epithet. I described the chain above. If the brain is ready, the process will line up by itself. Then the question in the choice of tools.
Well, now we are not perverts, but the right developers. How to harness a horse (stubborn test pony with short legs) and a quivering doe (developer's thought)?
So about the "thought." With the developer you need to hang out, drink beer (just kidding). Persuade. Entertain. Make him believe you. And to consider your thoughts as your own (hello Carnegie). In another way - no way. Make - not. Neither can you be forced to write good code. You can give a person a book McConel on his birthday. But no more than that. No administrative measures will help, and will only cause bitterness.
The toolkit we use is:
- DUnit.
- Improvements to DUnit ;
- Confluence ;
- self-made analogue of JIRA ; At that time JIRA was still “cheese”, so we did not take it; now — I think — they would take it;
- scripting machine ;
- FishEye (https://www.atlassian.com/software/fisheye/overview);
- Improvements to Confluence and FishEye that allow you to track the link of commits, code changes and linking specific code changes to specific tasks;
- integration of UML and Confluence;
Who creates the tests? And if the "role" of the test creator does not imply knowledge of programming?
Tests are created by developers. If we are talking about new functionality.
Or testers. If we are talking about errors.
And most often, testers write an error and immediately write a test for it.
Here, by the way, you need to understand one simple thing, TZ and errors in general are not fundamentally different from each other. Only "area of ​​responsibility."
“And if the“ role ”of the test creator does not imply a knowledge of programming?” - on BDD or Fit-Tables - we haven’t “raised the mark” yet, but we are working on it.
Is TDD our “all” or do you recognize the limitations of this technology?
“It’s ruined in the heads, not in the code.” No limitations. There is a reluctance to apply.
Is the TDD technique applicable to all systems? Are there “special cases” or “other approaches”?
No "special cases." There is a desire of developers to “sleep well” and not think too much, keeping the nerves.
There is something that can be thrown out of TDD, there is something that can be brought. But in general, TDD remains and guarantees no panic. Panic-Driven Development is excluded.
What led you to TDD?
Need. As the complexity of the system grows, we understand that “we are doing one thing”, “another is falling off”. Then the tests have become a necessary component. We came to them evolutionarily, but sooner or later they all come to this. Also evolved into TDD. Suddenly it turned out. That tests are not only useful, but also convenient. No need to configure the infrastructure every time. They wrote a test, the environment for debugging is ready, run this test at least a million times. So who has already "felt" - welcome to TDD.
What do you think could be better than TDD?
BDD. There are people in the world of Delphi who do this and promote it. Roman Yankovsky is working on it. Well, fit-tables. If there is a desire to develop, then you can reach a lot yourself. Or use the half hints, sketchy articles, Wikipedia (in extreme cases). But today I talked about a really working process. I write in detail in my blog, but the communication with the audience proved (going beyond the readers) that the main problem is in understanding the value of TDD. Today I tried to tell about it.
Nothing that some of the questions sounded like "trolling"?
In life, this did not happen when TDD was introduced into the production process. Normal reaction.
Test Driven Development - an attempt to follow the fashion? Blindly copying other people's approaches?
Let's "immediately determine." I do not use TDD in its classic sense. And do not quote here "Wikipedia"! In general, it is unlikely that someone from professionals considers encyclopedic articles as a guide to action. We “suffered” our approach as part of a successful project, so we have real experience, not “stupid use of other people's ideas.” Rather, we use synthesis from TDD and our own ideas about how to develop software. Even if these “external ideas” come from very smart people, they should be critically interpreted and adapted to the real company, the existing team and the strategy of development and quality assurance. But I will continue to say "TDD", referring to the process of "developing through testing", which closely correlates with the encyclopedic Test Driven Development, but goes much further than it.
')
TDD is an attempt to turn everything upside down. In the engineering classics, an installation / technical system / machine / unit is first created. Of course, the test method is meant when designing ... but still, programmers are some special kind of engineers? Genetically flawed? Do not you consider yourself so?
It all depends on the definition - that "head", and that "legs." And as you know, the most scientific debate is a debate about terms. If we talk about the test procedure as a self-sufficient and deeply developed discipline, then we can not say that it is on an industrial scale. Then she would de facto be present everywhere and there would be no controversy in principle. But this, in fact, does not distinguish us fundamentally from other engineers who, for example, make coffee makers, lawn mowers or bicycles (not to be confused with “bicycles”).
Do I consider myself "genetically flawed"? By virtue of the profession, in part, yes. Therefore, I strive with all my strength to become better. Software development is an engineering craft, so you don’t have to suddenly consider yourself a superman or some creator. We are artisans (with the exception of units), this must be realized and reconciled. And try to become a normal (and not a genetically detrimental) engineer - tolerances, drawings, test methods, etc.
TDD - constrains developer initiative. It is no longer the developer himself who controls the process, but the task “falls on him with snowballs”? Is there any psychological discomfort? The programmer is no longer a creator, but a thoughtless machine of how to implement the functionality?
On the contrary, TDD does not constrain anything, but allows you to work more productively. Of course, “productively” means “working more.” Instead of one class, you have to write two: the projected class itself and the test for it. TDD is just for enterprising people. Who love their work. If there is a desire to optimize (= save your work time), then it is already at the door with the inscription "for idlers". Potential idlers or people practicing idleness during working hours may no longer read.
Only no one controls the developer, he controls himself - "beats his hands." But this is not masochism. Instead, the developer gets something important - a sense of stability and confidence in their professional tomorrow. And as a creator - he creates twice as much. It is creating, not "plowing." He just plows less. I am waiting for the next question for clarification.
TDD - puts at the forefront not the quality of implementation, but momentary features. How can you talk about code quality? About system architecture? From the point of view of the program code, we get “olivier salad” - a mechanical mixture of finely sliced ​​pieces of different flavor and color? Do you believe that from a vinaigrette, folded in a large group can symbolize an architecturally perfect and constructive quality?
This is absolutely not true. It is quality and stability that is put at the forefront. Just, there is a “feature” - there is a test confirming that this is a “feature” and not a “bug”. What did not fall into the TZ, then did not fall into the tests, whence then will it take in the functional? Only this way: the customer’s desire is expressed in the TZ, from there it flows into the tests, and only then the functionality appears.
Now, about architecture ... Architecture is not something universal and self-valuable. And do not have a silver bullet. And not what a bad bullet is made of. I know the architecture of the system, because I have been doing it for 15 years and I know it very well, thanks to the UML drawings. I have a complete set of design solutions in the form of UML diagrams. But here there is a chance not to keep everything in memory. How to restore all this in memory? Just look at a specific test.
Tests are “archived memory”, as well as “documentation” and “use cases”.
In this case, the tests are more stable and invariant compared to the project code. The code is reborn. Evolving. Dies. With tests, this happens much less frequently. You see, there is no conflict of interest between the architecture and the tests. And they are in their bundle more important than the code.
TDD - a scourge that whipped disobedient IT-slaves? Is this some kind of "council" for freedom-loving people, proudly referred to as "developers"? You, developers, should not think. Your job is to pull the strap, to fulfill the plan for the shaft! Look at the tests given by you from above, and do not even dare to take the initiative!
So this means ... “Management”, (to the Directorate and especially customers) really doesn’t matter what technologies are used (with rare exceptions, which we will not hope for). In general, no one soars, and what's "inside" the developers do? They use RUP, TDD / ShmeDD, Agile / SuperAgile or something else ...
All the above listed “stakeholders” - the result is important, not the process. No sensible boss will impose TDD. He needs the result, not the irritation of the developers - “this clever man again imposes some newfangled pieces on us”. A smart boss ... really smart (in IT it is more often than in other areas) can only make the developers feel the need themselves. This is the only way, otherwise it is a dead end.
There are no tests given above. Tests are an internal matter for developers. And the better the tests and the more of them, the developers “sleep better”. And the less they are called on the carpet. Tests - for developers, not for chiefs.
TDD is an attempt by incompetent and far from coding people to promote their ideology alien to developers ... their own, often wrong vision of the product development strategy.
Again. Tests are not dictated by the “directorate”, the management or the customers. Tests are a development tool. Tests are the “internal kitchen” of developers and quality groups. All other "stakeholders" operate TK. Well, or "screens." Maximum ... Tests and "development strategy" do not correlate at all.
Suppose I was obliged to follow the TDD technique, although, you see, many people feel comfortable without it. Well, what does this give in comparison with normal technology, when “we planned - implemented - did tests - tested”? Just a “beautiful fairy tale” for the boss “are we using cutting-edge approaches?”
You can be such a stubborn opponent of TDD! "Require" to use tests impossible. You can only persuade. If someone feels comfortable without tests, it means that:
- his project is not so complicated;
- it tests everything on real users (they are not lucky)
- He is a genius;
- he works alone.
Let's look in the mirror and choose our category.
Once again: “Fairy tales” - no, the administration doesn’t care, it needs a result, time and quality.
I plowed tests. Began under them (reluctantly) customized functional code. It turns out ... then that the test was invented incorrectly. I wasted for nothing?
Here "plow" nothing. One feature - one test. Iteratively. A feature spawns a test, and a test spawns a feature. XP, kiss-principle.
And there is no such thing that the “tests”, which acquired the form of a “hard task,” began to contradict each other?
This is my favorite question from the category of "brilliant"! If tests contradict each other, then:
- TK is not well developed;
- TK is contradictory.
Then you need to say "thank you" to the tests and return to the elaboration of the TK
TDD is a waste of time. Let's first write the code, and then we will test it. Any walking backwards, an unnatural order of development, even if it does not affect the quality, will necessarily cause a brake.
Is logical. So many do. Let's write the code. We will write. Let's fix it in CVS / SVN. So what? Have we done our job? Type "how lucky"? To ride / not to ride? Could be so. Only then will they “raise you out of bed” and ask “what the hell are you writing here?” So?
You can in another way - write the code and check it. And how are we going to check it? Stupid poking?
And if for “poking” you need to take 20 steps? And if 100? And if "no data"? And if "subcontractors are not ready"? Isn't it easier to “write a test” at least for debugging? With invented "from the head" input and output. In my opinion, easier. And if the test is ALREADY written and used for debugging, then why not include this test in the "nightly build"?
TDD - a way to put a developer in a demeaning position. "Broken unbeaten luck." The programmer works “from the feeling of guilt” in the permanent state of non-realization of the task.
On the contrary, the programmer has always “fixed points”. Here I wrote a test. He does not pass. Here I implemented the functionality. The test began to pass.
I did everything in CVS / SVN. I have done my work and “can sleep well”.
TDD - is there a feeling that the programmer is solving the inverse problem all the time? Or is the developer a Loser, customizing the solution to the answer of the problem?
And programmers always solve the inverse problem. Well, or "build a spherical horse in a vacuum." A programmer is not a loner, but an ordinary person who cannot foresee everything. But what he provided for is guaranteed to work. There are other people. But they are geniuses, but they are few.
TDD - development in the looking glass. We performed tests that are not a guarantee of infallibility. Who is responsible for the quality of the tests?
There is no guarantee of complete infallibility. There is only a guarantee that the developer correctly understood the TK and implemented it as it understood it.
TDD - a cart in front of the horse. The horse constantly pokes its muzzle “into the rear bumper”, not seeing anything ahead of itself. How can you talk about thinking through the functional as a whole at the level of the system architecture, when ahead - far into the horizon - just a dump of needs?
Here again, let's go back to the "most scientific dispute." We define the terms that is a cart and what is a horse. And I do not need to threaten Wikipedia (how can I test what is not)?
So it will be right:
- “horse” is TK;
- “cart” is CODE.
And what are the tests? Tests are “shafts” with which the horse is tied to a cart. The whole process of TZ is lucky, and the tests pull the code behind them and check its compliance with the TZ. The code goes in the same direction as the TK. There is no TestFirst! Neither CodeFirst! There are TK-first. But this is if simplified. The chain looks like this: TK -> Architecture Sketch -> Test -> Code, and then options are possible.
TK -> Architecture Sketch -> Test -> Code -> Test -> Code
TK -> Architecture Sketch -> Test -> Code -> Architecture -> Test -> Code
TK -> Architecture Sketch -> Test -> Code -> Architecture -> Test -> Code -> TK -> Architecture -> Test -> Code
…etc. etc.
First: TK and architecture sketch, then the iterative development begins.
And what is especially tasty, that as soon as we wrote a test, we do not need to think, but where to check the performance of our class? We have already configured the entire infrastructure for its testing and verification. This is what the word Driven in TDD means.
Well, there are "perverts" in the world. Then how can you alleviate the suffering? What is the correct process for this?
No, well, thanks for the epithet. I described the chain above. If the brain is ready, the process will line up by itself. Then the question in the choice of tools.
Well, now we are not perverts, but the right developers. How to harness a horse (stubborn test pony with short legs) and a quivering doe (developer's thought)?
So about the "thought." With the developer you need to hang out, drink beer (just kidding). Persuade. Entertain. Make him believe you. And to consider your thoughts as your own (hello Carnegie). In another way - no way. Make - not. Neither can you be forced to write good code. You can give a person a book McConel on his birthday. But no more than that. No administrative measures will help, and will only cause bitterness.
The toolkit we use is:
- DUnit.
- Improvements to DUnit ;
- Confluence ;
- self-made analogue of JIRA ; At that time JIRA was still “cheese”, so we did not take it; now — I think — they would take it;
- scripting machine ;
- FishEye (https://www.atlassian.com/software/fisheye/overview);
- Improvements to Confluence and FishEye that allow you to track the link of commits, code changes and linking specific code changes to specific tasks;
- integration of UML and Confluence;
Who creates the tests? And if the "role" of the test creator does not imply knowledge of programming?
Tests are created by developers. If we are talking about new functionality.
Or testers. If we are talking about errors.
And most often, testers write an error and immediately write a test for it.
Here, by the way, you need to understand one simple thing, TZ and errors in general are not fundamentally different from each other. Only "area of ​​responsibility."
“And if the“ role ”of the test creator does not imply a knowledge of programming?” - on BDD or Fit-Tables - we haven’t “raised the mark” yet, but we are working on it.
Is TDD our “all” or do you recognize the limitations of this technology?
“It’s ruined in the heads, not in the code.” No limitations. There is a reluctance to apply.
Is the TDD technique applicable to all systems? Are there “special cases” or “other approaches”?
No "special cases." There is a desire of developers to “sleep well” and not think too much, keeping the nerves.
There is something that can be thrown out of TDD, there is something that can be brought. But in general, TDD remains and guarantees no panic. Panic-Driven Development is excluded.
What led you to TDD?
Need. As the complexity of the system grows, we understand that “we are doing one thing”, “another is falling off”. Then the tests have become a necessary component. We came to them evolutionarily, but sooner or later they all come to this. Also evolved into TDD. Suddenly it turned out. That tests are not only useful, but also convenient. No need to configure the infrastructure every time. They wrote a test, the environment for debugging is ready, run this test at least a million times. So who has already "felt" - welcome to TDD.
What do you think could be better than TDD?
BDD. There are people in the world of Delphi who do this and promote it. Roman Yankovsky is working on it. Well, fit-tables. If there is a desire to develop, then you can reach a lot yourself. Or use the half hints, sketchy articles, Wikipedia (in extreme cases). But today I talked about a really working process. I write in detail in my blog, but the communication with the audience proved (going beyond the readers) that the main problem is in understanding the value of TDD. Today I tried to tell about it.
Nothing that some of the questions sounded like "trolling"?
In life, this did not happen when TDD was introduced into the production process. Normal reaction.
Source: https://habr.com/ru/post/206828/
All Articles