A Test-Driven Mentality

Tests still come first in your approach to legacy code. You will need to write tests to characterize existing behavior, even though these tests cover code already written. You will also test-drive any new code you write.

You’ll likely realize that writing tests after the fact (something I refer to as Test-After Development [TAD]) requires considerably more effort than had you created the code using TDD. The primary reason is that programmers don’t structure their code to be easily tested if they’re not worried about testing it. The second reason is that when test-driving, you should be continually factoring toward smaller, more reusable elements that make the crafting of new tests and code easier.

Testing the open function looks like it will be very time-consuming. We’d have to create or find one or more WAV files that we could test with. We’d need to read the resulting output file and check all of its content. That’s a lot of detail that we don’t have time for now.

Life can be simpler. You really only need tests around code you will change, a baseline that tells you when you’ve broken existing behavior. You do not need to test code leading up to that area of change, although you will need to determine what dependent code might break as a result.

You also want to avoid tests that must interact directly with the filesystem in order to keep your test suite fast and to reduce the headaches of managing files. You can partially accomplish that by using in-memory streams where possible instead of file-bound streams.