Testing: Cleanup Test resets

[kmanning]

• This library unfortunately has a lot of static state
• You'll find a number of classes that have a reset() method, so that as we run unit tests, state modifications from one test don't unintentionally impact another test
• This is really error prone, is difficult to detect when missed, and is just difficult to maintain. This feels like an anti-pattern.
• Find a better solution for this.
• Part of the solution is likely implementing a JUnitRule instead of @Before/@after reset() methods

[kmanning]

What if each class could register itself as "resettable". Then the rule would automatically iterate across every resettable object, between each test case. Then all a Dev would need to do is call the single JUnitRule, and not worry about the details of what's being reset.

[jantman]

Is there any way to have JUnit/Gradle run each test in a separate process? Is that a thing? When I've come across issues like this in other languages, either with static state or with import-time issues in dynamic languages, I've solved it by using a test runner that has the option of running each test in a completely new process/interpreter...

[kmanning]

JUnit 5 has replaced @Rule with @Extension - https://junit.org/junit5/docs/current/user-guide/#extensions
Now that Issue #332 is resolved, the we've upgraded to Junit 5, create an Extension to reset any global state consistently between tests.

[kmanning]

Solution:

1. Any class that has static state should implement Resettable, and add a reset() method that restores static state
2. Any Test that modifies static state should use the ResetStaticStateExtension