There is an informal rule: “It doesn’t matter how loudly you shout or how often you scold the programmers, no matter how thick the rod you hit them with, no matter what and how you threaten them. The only thing that matters is that programmers will only use a tool or process if they believe that those tools or processes will make their job easier. ” Of course, this rule applies not only to programmers. Therefore, it is important to prove to programmers that unit testing will save them energy, nerves and help them make more money. here is a good post to read about how to become a game developer https://thewiidownloadsreview.com/what-you-need-to-know-for-becoming-a-game-developer/
It is impossible to implement TDD by force
Unfortunately, we do not have rich experience in introducing testing into a new team, but according to many TDD proponents, one of the most effective techniques for introducing TDD into a team of “traditional” programmers is the “infection by example” technique, that is, introducing TDD first by a small group of developers ( even if it is only 1 programmer), and then through episodes of pair programming, through parsing the code, through searching for errors through tests – gradually involve others in the process. After the critical mass has been accumulated, it is possible to get rid of those who do not agree to a complete transition, although most likely there will not be such.
We at Connected IT Consulting strictly follow the TDD implementation of code on ERP Project Management, because if there is a minor mistake that can create havoc.
The task of those people who implement TDD for the first period is to infect the most active ones. Of course, TDD should be implemented by someone who already has a lot of testing experience, since unit testing, if used incorrectly, can cause various troubles.
You need to “infect” others personally, by example. Small sessions of pair programming while creating the code – what the doctor ordered. Suppose someone asks you to implement some new functionality in the part of the code for which you are responsible, you call the developer who requested the feature to help you a little.
With the help of tests, you try to show whether you have understood its requirements correctly, or whether it is precisely required from your new code. Next, you can ask him to help make the implementation. What will refuse to help? You and your partner do the implementation, run the full suite of tests, and make sure everything works as it should. As a result, your partner gains experience in testing and pair programming.
With such a gradual implementation, there may be some, sometimes very serious difficulties for pioneers. Let’s say you are the person who starts implementing testing in the team. You write your code, supply it with tests, and when you get the green bar, you push it to the repository. Other developers, especially at first, are likely to ignore “all this test stuff” and commit commits without running that test suite of yours. After a couple of days, you might easily find that your tests no longer fire and you have to do extra work to get the test suite to fire again.
It is good if, using your tests, errors are found in the new code, in this case, it will be possible to conduct a public analysis of the situation – you need to use every chance to show the usefulness of testing. Ask the developer who committed the broken code to check if the functionality of the program that you know has broken is working.
You will need to tell him that you learned about this error in the program using your tests. Then you can show him the failed test and try to fix the situation together. It is even better if the developer does not know how to fix the error and asks for your help in this. In this case, he is very strongly motivated to use tests to find the place where errors were made, and maybe even try to expand the set of tests to introduce new checks. Your task is to help him in this.