From Nothing to System Tests
Blog post series
This blog post is part of a series about legacy coderetreat and legacy code techniques you can apply during your work. Please click to see more sessions about legacy code.
Whenever I need to change an existing system I need a safety net. These system tests knit a coarse safety net, very good if you want to have the safety of changing code later without introducing defects.
This is the first thing I usually do when I start working with a system that:
- does not have any automated tests
- is totally unknown to me
This safety net will be used during the next phases when the code will be refactored and cleaned-up, before being modified. Now let’s see a bit about the concept of this session.
Before starting to change any legacy system you need to know you will not introduce any defects when changing the code. So one way would be to stay on the safe side and start writing some automated tests. These tests can be Golden Master type of tests, they can be Characterization Tests, or anything else that might give you this certainty of correct changes in a later stage.
The art of working with legacy code systems is to understand which is the minimum amount of tests you need to write in order to change the least code for finishing the modification(s). So this is why you might want to start with an analysis beforehand. I usually think at the following things:
Question: What do I need to do?
- Fix bug or
- Change behaviour or
- Make the system easier to change for the future or
- Cover with tests the core part of the system.
Question: What modules/classes does this modification impact?
- Make a list and
- Order them in an a top down way, starting from the user interface
Question: What are the options of modification?
- Find the modification options and
- Order them from the simplest to complicated and
- Create a short modification plan
This step takes me minutes at most. I often do this in my mind, by it helps using index cards to write these answers down. After these steps I start with writing the system tests on the thinnest layer of the vertical system, starting from UI or from immediately underneath the UI, depending on the system.
Important: Do not change the code in any way before you have enough tests. What is enough? Depends on the system. You might want to use a test coverage tool, or just use your instinct.
- Learn how to have a safety net that you can use to add more tests.
- Find different techniques of building this safety net without changing the code.
- Learn how to use the tests that create the safety net and where you might need to take special care.
Important: At all times make sure you have tests that are as short as possible, using variable and method names coming from the domain of the problem.
This session has some prerequisites:
- Good knowledge of unit testing and test doubles, especially mocks, stubs and fakes.
- Very good knowledge of the programming language you use. You often need to use some hacks that will allow you not to change the existing code and be able to test it.
- Open mind to new, sometimes mind-blowing, techniques and concepts.
Further it is very important to have good knowledge about software design, especially techniques of decoupling the existing code. It would be a good thing that any attendee would know about the SOLID Principles and have basic knowledge about Design Patterns.
I thought about this session as a higher level abstraction of the session on Golden Masters that JB Rainsberger presented at the first Legacy Code Retreat. As Golden Masters is a technique applicable in certain cases, I think you always need some kind of system tests before taming a legacy system.
So during this session you can find practice, depending on the audience and the facilitator, any type of technique that can produce a first, coarse, safety net for you.
Please find here a code cast in Java about this session
Image credit: http://upload.wikimedia.org/wikipedia/commons/7/7f/Snake_warning_sign.jpg