Suppose you have been put in charge of an already existing project. As you are starting to familiarize yourself with the repository, you notice a few technical debt issues (insufficient test coverage, conflicting standards, missing documentation, etc). As someone who is going to be working on this project and maintaining this code, you add this to the backlog of the project with a goal to slowly reduce it over several releases.
Your policy on this technical debt is:
- This technical debt can be detected and measured by unit tests.
- You want to use unit tests to detect and measure this technical debt instead of relying on code reviews where humans can miss things.
- For each development, is acceptable for the amount of technical debt to stay the same or decrease. It is not acceptable for the amount of technical debt to increase.
- The technical debt that currently exists is expected to be slowly reduced and eliminated over several releases.
(The above may apply to only a subset of the total technical debt instead of all of it; for the purpose of the question we are considering only the technical debt where the above is true.)
There are a few approaches that I have identified, but they have downsides:
- Set up unit tests for different sections of the code that will pass when the technical debt is cleared. This has the downside that for a long period of time releases will have to be performed with failing unit tests.
- Set up unit tests that will pass if amount of technical debt is below a certain threshold. This has the downside that if the technical debt level is decreased, it is possible for more technical debt to "sneak in" before the threshold is reduced.
- Set up unit tests, but whitelist certain objects or sections of the code so that the tests always pass for the whitelist. This has the disadvantage that if a development interacts with the whitelist, the tests will pass even if the developments make the whitelist objects worse.
What is the best approach to take in this situation?