There are only two kinds of safely-reusable code when it comes to tests. The first is setup/teardown code that is used for multiple tests within a single fixture, and that is as far as that code’s reuse goes. The second is standardized test object instantiation code that can be factored into formal (and very-carefully-maintained!) Object Mothers.

Trying to reuse anything else has always resulted in test code that is reused and then modified for the sake of one test such that it causes another test (or a number of tests) to no longer operate correctly. Such impacted tests have a nasty tendency to then either still pass when they should have started failing or to start failing when they should have kept passing. Diagnosing such situations has usually proven a more expensive problem than the duplication which is its alternative.

I’ve even given the boot to test base classes with setup/teardown behavior that is effectively shared by derived test classes. These too have more often than not created the same issues as any other reuse outside of the two types I mentioned, even though one might be tempted to consider base class setup/teardown to be among the former kind of safely-reusable test code. I don’t even count that as safe any more.

And it needs its own tests.

Once, I made that realization things pretty much fell into place for me.

If you have tests that have a lot of refactored code, then create a test framework and treat it like you would other solution code.

With that realization:
- copy test code if it isn’t worth the effort of building a properly developed framework
- if it is worth the effort then readability is much better. You have tests that explain the purpose of the code: you have the same support you have for the rest of your solution code.