CODEWITHSUNDEEP
c#unit-testing
Hélder Gonçalves
Hélder Gonçalves

Reputation: 3942

Unit testing while migrating legacy code

We have an old C# Library that needs to be "cleaned", refactored, basically redone. This library does not have any unit testing associated (and no documentation for that matter). We want to assure that after remaking everything from scratch, all the features are kept and no bugs are introduced. For that I ask you, how would you approach a situation like this thinking about unit testing. Should I create unit tests for both the old project library and the new one? There's no point in creating unit testing for the legacy code. Or is it?

Upvotes: 3

Views: 192

Answers (3)

Myrtle
Myrtle

Reputation: 5851

So, no unit tests exist for the legacy code as well. Theoretically we're even not sure it is bug-free.

Unit testing legacy code requires some re-factoring techniques that also requires you to change the legacy code. If the plan is to write a new library, unit testing the old one doubles the work and wont give you any good insights.

You want to know whether no bugs have been introduced: Build the new project test-driven. You want to know whether the functionality is the same? end-user acceptance testing as there is no automated way to verify whether the new and the old one behave the same.

I missed the part it is an inner component being used by other components instead of a user. In this case you can write black-box tests. This does require you to keep the public contracts the same, however allows you to identify differences between the old and the new project.

Upvotes: 1

k.m
k.m

Reputation: 31484

This unfortunatelly depends on how you plan on rewriting. If you want to completely redesign, then writing unit tests for legacy code will be more or less useless and you won't be able to migrate them. Unit tests are tightly coupled to unit they test. Redesigning units under test usually invalidates their unit tests.

I suggest considering writing integration tests for old library, i.e. to verify large processes (if that's even possible). They might be more salvagable and should give you sense of assurance that the broad picture is still intact. But that might be highly domain-specific, i.e. if you're migrating sort of tools library, there might not be a broad picture to look at!

Upvotes: 1

Sergey Kolodiy
Sergey Kolodiy

Reputation: 5909

If your goal is to keep existing API unchanged and only improve the internal implementation of your library, you should cover public API of your old library with unit tests. Then you'll be safe to do refactoring and improvements.

If your improvements require changes of public API, unit tests for the old library wouldn't help — you should cover new API with unit tests.

Upvotes: 0

Related Questions