Testing a module when porting legacy code
We have an old C # library that needs to be "cleaned up", refactored, mostly redone. There are no test-related units in this library (and no documentation for that matter). We want to assure that after reworking everything from scratch, all functions are preserved and no errors are introduced. To do this, I ask you how would you approach a situation like this thought of unit testing. Should I create unit tests for both the old project library and the new one? There is no point in unit testing legacy code. Or that?
source to share
This unfortunately depends on how you plan to rewrite. If you want to completely reverse engineer, then running unit tests against legacy code will be more or less useless and you won't be able to port them. Unit tests are tightly coupled to the device under test. Redesigning devices under test will usually invalidate their unit tests.
I suggest considering running integration tests against an old library, i.e. checking large processes (if possible). They can be more accommodating and should give you the assurance that the big picture is still intact. But this can be very domain specific, that is, if you are porting some tool library, there may not be a big picture to look at!
source to share
So there are no unit tests for legacy code. In theory, we're not even sure if this is a bug.
Legacy unit testing code requires some re-factoring techniques that also require changes to legacy code. If the plan is to write a new library, the module testing the old one doubles the work and won't give you any good ideas.
You want to know if errors were introduced: Create a new test driven project. Do you want to know if the functionality is the same? end-user acceptance testing, as there is no automated way to check if new and old are the same.
I missed the part, this is an internal component used by other components and not by the user. In this case, you can write black box tests. This requires you to maintain government contracts in the same way, but allows you to differentiate between the old and the new project.
source to share
If your goal is to keep the existing API intact and only improve the internal implementation of your library, you should cover the open API of your old library with unit tests. Then you will be safe to refactor and improve.
If your improvements require changes to the public API, unit tests for the old library would not help - you have to cover the new API with unit tests.
source to share