Unit testing – unit testing is worth the effort, in a large and old (5yr) code base?

I just joined a team that has been working in the main mode for the past five years (Java, Maven based projects) Therefore, the plan to use unit testing has been ongoing and has never been implemented (so far) A great development team ensures that the code quality is generally good, there are no structural code problems, but there are no written tests However, I see the benefits of unit testing as a lonely warrior who promotes the adoption of automated testing

The team layout enables the individual test team to manually test the functions before launching the code. The change management team is the inspection of change approval and construction (there is no continuous integration so far)

Here are the obstacles: because the code base is huge and some original developers have left the team, any additional unit tests may be too few and too late Plus it, I'm probably the only one driving unit testing Although my manager has always supported this idea, he does not want to deadlock the additional time required for the change team to be tested and run

I think we can start with a separate CI tool, and the change team must change the script to skip the test when adding

What would you do in my shoes?

I know there is a similar problem in stack overflow, but the purpose is to convince different stakeholders and the best way Not a technical comparison

Solution

It sounds like you have a good handle on this situation

Two things:

>Don't expect to be able to completely unit test a 5 - year project Suppose five developers have worked for five years, and your working hours are about 50000 Assuming that testing takes a lot of time to write code, you will get 2-3% coverage in a year So: test the new code and write tests to modify the old code Get time / take time to set up some type of CI Gradually, you will build a good test battery

Since you obviously didn't drown the bug, start slowly and gain momentum