Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Test, Code, Test
Refactoring is a great way to start getting used to the rhythm of test-driven development, an approach in which you start a refactoring exercise by writing a test, changing some code, and then making sure that the test still works. (If you're curious about that, Google for "red-green-refactor.") Of course, you're not writing failing tests. By putting a test harness around legacy code after the fact, you're doing the refactoring that should have been done in the first place.
After a few rounds of refactoring, you should start to notice responsibilities of classes breaking out. At some point, as you factor out code that deals with things like database access and infrastructure, you reach a point where you can unit-test your logic separately from the infrastructure[md]where you're actually unit testing, rather than integration testing. At this point, you can start to move some of your integration tests[md]for example, things that require access to a database to test a result[md]to something that doesn't have to run every time you check in code.