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.
Of course, there are other cases that are not related to catching errors. A couple of years ago, when we were just introducing tests into our work, such situations were not uncommon, even among those developers who wrote the tests. In a situation of limited time, changes were sometimes made without taking into account the tests, they were completely forgotten, and then they had to pay triple.
Of course, it is very difficult to implement testing in a project with collective code ownership if everyone is constantly “hammered” on tests. Therefore, at the very beginning of the implementation of unit testing, you should have at least an area of personal responsibility, that is, code that cannot be changed without an owner. In this case, the effect of injecting tests for the code in your area of responsibility will be very strong.
So, the first step is to prove to the most active developers the advisability of running a group of tests just before committing. They will definitely love the confidence that everything works as it should and nothing breaks, even if these developers do not add new tests to the system just yet. It is necessary to show real examples of using tests. When the tests are run often enough, some will try to write the simplest tests themselves. Your task is to help them not to quit. Further, the testing epidemic will spread quickly enough.
People who have never experienced the charm of TDD (or saved a few hours because they had a good test suite) see tests as a waste of time or resources. They are probably right, since their applications always work without errors, since they do not spend many hours debugging their applications, since they manage to make a high-quality design the first time. The key point is how to explain that tests actually save time and effort in coding, making the developer’s life much easier. Usually people agree easily, at least try testing, especially if there is a person who can convey the very essence. And if they like it, they will continue to use this style of work.