Test Cocooning

 "How do you deal with Legacy code that lacks test coverage?" - even miniscule small changes are hazardous, and often, a necessary rewrite is postponed forever because it's such a nightmare to work with. Even if you have invested time into your test coverage after taking over the system, chances are there are still parts of the system you need to deal with that aren't covered at all. So this is what I propose in this situation:

Test Cocooning is a reversed TDD cycle, and it should be common sense.

The Cocooning process

Test Cocooning is a pretty straightforward exercise: 

1. Based on what you think the code does, you create a cocooning test.
1. If the test fails, you didn't understand the code correctly and you have to improve your test.
2. If the test passes, you have covered a section of the code with a test that ensures you don't accidentally break the tested aspect of the code.
2. Based on what you think the code does, you make a breaking change.
1. If the test fails in the way you thought it would, you have a correct understanding of that piece of code.
2. If the test passes, you didn't understand the code correctly and you have to improve your test (back to step 1)
3. Intermediate activity: Of course, you revert the change to restore the behaviour that you have covered with test.
3. Within the scope of your passing test, you begin to improve:
1. Create lower-levelled tests that deal with more specifics of the tested code (e.g. unit tests.)
2. Refactor based on the continuous and recurrent execution of all the relevant tests.
3. Refactor your tests as well.
4. Re-run the original cocooning test to ensure you didn't mess up anywhere!

Once a cocooning cycle is completed, you should have reworked a small section of your Legacy code to be Clean(er) Code that is more workable for change.

Iterating

You may need to complete multiple cocooning cycles until you have a sufficient amount of certainty that you have workable code.

Backtracking

The important secret of successful Test Cocooning is that you need to backtrack both on the code and your tests - after completing all relevant cocooning cycles, you'll need to re-run:

• your cocooning tests against the original legacy code. 
• your unrefactored original cocooning tests against the new code.
• your unrefactored original cocooning tests against the original legacy code.

Yes, that's painful and a lot of overhead, but it's your best bet in the face of dangerous, unworkable code, and believe me - it's a lot less painful than what you'll experience when some nasty bugs slip through because you skipped any of these.

Working Cocooned code

Once you have your test cocoon, you can work the cocooned code - only within the scope of your cocoon - to fix bugs and to build new features.

Bugfixes

Fixing bugs relies on making a controlled breach to your cocoon.

Metaphorically speaking, you need to be like a spider that caught a bug and sucks it dry before discarding the woven husk.

1. Create a test cocoon for the current behaviour which passes under the current faulty(!) conditions of the code segment that exactly reproduces the bug as though it were desired behaviour.
2. Create a test which fails due to the bug, i.e. add a second test that exactly reverses the cocooned behaviour.
3. Write the code that meets the requirement of the failing test.
1. As a consequence, the cocooned passing test for the bug should now fail.
2. Ensure that no other tests have failed.
3. If another test has failed, ensure that this is intentional.
4. Eliminate the broken cocoon test that reproduces the bug's behaviour.
1. If there were other tests that failed, now is the time to modify these tests one by one.
5. Backtrack like described above to ensure that nothing slipped. 

Modifying features

Modifying existing behaviour should be treated exactly like a bugfix.

New functionality

If you plan to add new functionality to Legacy Code, your best bet is to develop this code in isolation  from the cocooned legacy and only communicate via interfaces, ensuring that the cocoon doesn't break. 

When you really need to invoke new code from the Legacy, treat the modification like a bugfix.

Rewrite

A rewrite should keep the cocoon intact. Don't cling to any of the Legacy code and consider your cocooning efforts "sunken cost" - otherwise, you risk reproducing the same mess with new statements. 

Closing remarks

1. I believe that test cocooning requires both strong test and development expertise, so if you have different specialists on your team, I would highly recommend to build the cocoon in pairing.
2. Cocoon tests are often inefficient and have poor performance. You do not need to add these tests to your CI/CD pipeline. What you must add to your pipeline is the lower-level tests that replicate the unit behaviour of the cocoon. It's totally sufficient to rerun the cocoon tests when you work on the cocooned Legacy segment.
3. Cocooning is a workaround for low-quality code. When time permits, rewrite it with Clean Code and you can discard the cocoon along with the deleted code.
4. Do not work on Legacy Code without a solid Cocoon. The risk outweighs the effort.