Home/ Questions/Q 6980573
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-27T18:02:25+00:00

Code evolves, and as it does, it also decays if not pruned, a bit

  • 0

Code evolves, and as it does, it also decays if not pruned, a bit like a garden in that respect. Pruning mean refactoring to make it fulfill its evolving purpose.

Refactoring is much safer if we have a good unit test coverage.
Test-driven development forces us to write the test code first, before the production code. Hence, we can’t test the implementation, because there isn’t any. This makes it much easier to refactor the production code.

The TDD cycle is something like this: write a test, test fails, write production code until the test succeeds, refactor the code.

But from what I’ve seen, people refactor the production code, but not the test code. As test code decays, the production code will go stale and then everything goes downhill. Therefore, I think it is necessary to refactor test code.

Here’s the problem: How do you ensure that you don’t break the test code when you refactor it?

(I’ve done one approach, https://thecomsci.wordpress.com/2011/12/19/double-dabble/, but I think there might be a better way.)

Apparently there’s a book, http://www.amazon.com/dp/0131495054, which I haven’t read yet.

There’s also a Wiki page about this, http://c2.com/cgi/wiki?RefactoringTestCode, which doesn’t have a solution.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Refactoring your tests is a two step process. Simply stated: First you must use your application under test to ensure that the tests pass while refactoring. Then, after your refactored tests are green, you must ensure that they will fail. However to do this properly requires some specific steps.

    In order to properly test your refactored tests, you must change the application under test to cause the test to fail. Only that test condition should fail. That way you can ensure that the test is failing properly in addition to passing. You should strive for a single test failure, but that will not be possible in some cases (i.e. not unit tests). However if you are refactoring correctly there will be a single failure in the refactored tests, and the other failures will exist in tests not related to the current refactoring. Understanding your codebase is required to properly identify cascading failures of this type and failures of this type only apply to tests other than unit tests.

    • 0