Spend time working on some test fixtures. You may not get a lot of tests written at first, but this investment will pay off.
When we start building a new green field project, it's a lot easier to write test-oriented modules. But when dealing with legacy systems, it may take more time to build a working test fixture. This may be tough to go through, but it's a valuable investment.
As an example, in Something is better than nothing, we talked about a system that scanned electronic files and put the parsed results in database tables. What steps would our test fixture require?
- Setup steps to clean out the appropriate tables
- Quite possibly, we may need to use code or a script to create a new database schema to avoid collisions with other developers
- It may be necessary to stage the file in a certain location so the parser can find it
These are all steps that take time in order to build a working test case. More complex legacy systems may require even more steps to gear up for a test run.
All of this can become intimidating, and may push us to drop automated testing and just continue with clicking through the screens to verify things. But taking the time to invest in coding this fixture will begin to pay off as we write more test cases that use our fixture.
Have you ever built a test fixture and had to alter it for certain scenarios? After having developed enough test cases using our fixture, we will probably encounter another use case we need to test that exceeds the limits of our fixture. Since we are now familiar with it, it is probably easier to create another fixture.
We will probably run into the situation where we need another test fixture that is totally different from what we've built. At this point, investing in the first test fixture doesn't have the same payoff. But by this time, we will have become more seasoned test writers and have a better handle on what works and what doesn't when it comes to testing the system.
All the work done up to this point will have sharpened our skill set and that, in and of itself, is a great payoff for investing in the test fixture.
Not at all. If our system interacts extensively with an LDAP server, we may need to code a fixture that cleans out the directory structure and loads it up with test data.
If the legacy system is flexible enough, we can put this whole test structure into some subnode in the hierarchy. But it's just as likely that it expects the data to exist at a certain location. In that situation, we may have to develop a script that spins up a separate, empty LDAP server, and then shuts it down after the test is complete.
Setting up and tearing down an LDAP server may not be the fastest, nor the most efficient test fixture. But if we invest the time to build this fixture to empower ourselves to write automated tests, we will eventually be able to refactor the original system to decouple it from a live LDAP server. And this whole process will sharpen our skill set. That is why creating the original test fixture truly is an investment.