When Miller first wrote SoftAutoCommitTest back in 2011, it was with the expressly started purpose to "Test auto commit functionality in a way that doesn't suck."
As the javadocs put it...
/**
* Test auto commit functionality in a way that doesn't suck.
* <p>
* AutoCommitTest is an abomination that is way to brittle in how it
* tries to check that commits happened, and when they happened.
* The goal of this test class is to (ultimately) completely replace all
* of the functionality of that test class using:
* </p>
* <ul>
* <li>A more robust monitor of commit/newSearcher events that records
* the times of those events in a queue that can be polled.
* Multiple events in rapid succession are not lost.
* </li>
* <li>Timing checks that are forgiving of slow machines and use
* knowledge of how slow A->B was to affect the expectation of
* how slow B->C will be
* </li>
* </ul>
*/
The jenkins failure emails (especially fromthe past few months) back up the implication that the strategy used in SoftAutoCommitTest is much hardier (even on flaky machines) then the approaches taken in AutoCommitTest and HardAutoCommitTest.
AFAICT there are esentially only 3 things these "bad" tests currently check that aren't already covered by the existing logic in SoftAutoCommitTest:
- maxDocs
- AutoCommitTest.testMaxDocs() currently checks the "softCommit" aspect (via newSearcher)
- nothing currently seems to test the "hardCommit" side
- commitWithin
- AutoCommitTest.testCommitWithin() currently checks the "softCommit" aspect (via newSearcher)
- HardAutoCommitTest.testCommitWithin() currently checks the "hardCommit" aspect (but also via newSearcher)
...I'll put my thoughts on these in individual sub-tasks
When Miller first wrote SoftAutoCommitTest back in 2011, it was with the expressly started purpose to "Test auto commit functionality in a way that doesn't suck."
As the javadocs put it...
The jenkins failure emails (especially fromthe past few months) back up the implication that the strategy used in SoftAutoCommitTest is much hardier (even on flaky machines) then the approaches taken in AutoCommitTest and HardAutoCommitTest.
AFAICT there are esentially only 3 things these "bad" tests currently check that aren't already covered by the existing logic in SoftAutoCommitTest:
...I'll put my thoughts on these in individual sub-tasks