threadly/threadly — pull request #79 by jentfoo (2014-04-23 20:05:54+00:00)
Title: This changes our unit tests code to hopefully be a lot more maintainable

I wanted to test all possible cases for the interface, but this was getting a bit hairy to do so. Because we use a lot of inheritance it would mean when ever we would add a test case for a given interface, we would have to add it in like 8 different places. This caused a TON of small little functions that just would call into the static implementation of the test.

This changes that by actually making the tests extend each other in a similar structure to how the code does. We then just have to override a function to provide the actual implementation to be tested. In some cases we override the test case itself to provide more specific (or further) verification. This allows us to continue to have good visibility into what tests for what components are failing. While greatly reducing lots of small little wrapper functions.

The complexity comes in from classes which have unique behavior, or implement multiple interfaces. The limiters are the greatest example of this. It requires us to now have a test class per interface test case. So in the limiters case we have one class that is testing the limiting functionality, and a second one which is testing the general interface functionality (thus doubling the amount of classes to test the limiters). The TaskExecutorDistributor is another example, now needing a second class to test the implementation of the returned "submitterForKey" functionality.

For that reason I decided to avoid testing the wrappers in PriorityScheduledExecutor and PrioritySchedulerStatisticTracker, since those just depend on the PrioritySchedulerWrapper (which is already well tested). Otherwise those two would have required two additional classes.

All in all, I think this makes the unit tests code smaller, and more maintainable, but look forward to feedback from the other developers.....2744 less lines of unit testing, with no reduction in code coverage (arguably better coverage for override implementations in the future)