You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While the test framework can run with the standard NUnit test runner and we have managed to make it work, it is missing the ability to reproduce a random test failure, which is crucial for debugging some of the more complicated random tests. Lucene uses a custom JUnit test runner called RandomizedTesting to accomplish this.
It also includes some other nice features
Ensure when a test fails, the random seeds are included in error messages and logs
Code analysis to ensure the tests are setup properly
Run tests in a random order to ensure they are not dependent upon each other
Preliminary analysis shows that the API for NUnit allows building custom test runners and it is a close enough match to implement the functionality. Most likely, this will require a custom adapter as well, so the test runner can integrate into Visual Studio and dotnet test/mstest.
Do note that without doing some pretty heavy refactoring on the Codec, Directory, and LuceneTestCase classes, it is not possible to run tests in parallel within the same AppDomain because the codecs use a static variable to turn codec impersonation on/off. For now, it would probably be best to run tests serially.
I have opened a dialog with the NUnit team, trying to gauge whether we can get them to add the most important features we need, whether it will be entirely up to us to port the test runner and create our own Visual Studio / dotnet test adapters, or somewhere in the middle: nunit/nunit#3405
After updating the test framework to utilize the NUnit.Framework.TestContext.CurrentContext.Random property, I noticed that random test failures now repeat reliably until the next build. Whether or not there is a way to lock in that behavior from one build to the next, this is probably adequate enough to avoid porting the entire RandomizedTesting framework.
That said, it would probably make sense to create a new library with the random generators so they can be shared without a reference to our test framework and all of the dependencies that come with it. We should also migrate the extension methods for the Random class.
Lowering priority of this and removing the 4.8.0 version, as it is not required for the Lucene.NET release. It might still be useful to do this someday, so I am keeping the issue open.
While the test framework can run with the standard NUnit test runner and we have managed to make it work, it is missing the ability to reproduce a random test failure, which is crucial for debugging some of the more complicated random tests. Lucene uses a custom JUnit test runner called RandomizedTesting to accomplish this.
It also includes some other nice features
Preliminary analysis shows that the API for NUnit allows building custom test runners and it is a close enough match to implement the functionality. Most likely, this will require a custom adapter as well, so the test runner can integrate into Visual Studio and dotnet test/mstest.
Do note that without doing some pretty heavy refactoring on the Codec, Directory, and LuceneTestCase classes, it is not possible to run tests in parallel within the same AppDomain because the codecs use a static variable to turn codec impersonation on/off. For now, it would probably be best to run tests serially.
JIRA link - [LUCENENET-627] created by nightowl888The text was updated successfully, but these errors were encountered: