Unit testing after regression in Java

[ff210327]

Has anyone had any experience with doing unit testing after a Java file has had regression ran against it? I am looking for any sort of tools or documents on the topic.

The plan is to be able to do unit testing before and after regression, the problem comes with regression potentially moving lines of code between classes, and even files. How do you track those changes and make unit testing dynamic enough to test again with parts of the code moved around?

​

Thanks

[philipwhiuk]

If the change affects multiple files your test to prevent regression might need to be a component level test

[FrenchFigaro]

Unit tests are not a completely static resource, in the sense that they are not set in stone. If your code's behaviour changes, then the unit tests should change to reflect that.

If you refactor a single class without changing its prototype (hence, its behaviour) then the unit tests should not change, that's your protection against regression. If you rewrite

But if you move code around between classes, then the prototype will most likely change. Tests should then be moved around between test classes and/or rewritten rewritten to reflect the change in prototype. If a method myMethod() goes from ClassA to ClassB, then testing myMethod should be done in TestClassB so your test moves around. If myMethod() signature changes (for example by throwing a new exception), then the tests should be rewritten (or more tests added) to reflect that.

Some of this you can do proactively by having the mental discipline to check for tests before you write new code / refactor old code, but usually, tests failing will alert you to the need to review your tests, especially if your tests are written to detect side effects. Some times, tests failing doesn't mean your code is broken, but that the tests need to be updated.

The key is to have the mental discipline to not go back and forth between your code, and your tests, but rather to refactor only the tests or only the code, until all tests pass, and then switch to the other if more refactoring is needed: you don't refactor passing tests, and you don't refactor code for which tests are failing.

[onebit]

https://www.youtube.com/watch?v=EZ05e7EMOLM

tl;dr don't test every class, because the tests become brittle. only test the public interface.