NightOwl888 commented on issue #406: URL: https://github.com/apache/lucenenet/issues/406#issuecomment-771823942
> But we do still have to figure out if upgrading to NUnit 3.17 is worth while. Given that I don't personally use console messages that much in my own approach to debugging, I don't have a strong opinion either way, especially since I now know how to see the output in the exception messages. What are your thoughts? There is one issue: Xamarin tests (which I am currently doing work on) cannot use anything higher than NUnit `3.10.1`. However, the way forward is to downgrade to that version on `Lucene.Net.TestFramework` as well as add targets to all of the test projects for .NET Standard 2.0 and .NET Standard 2.1, which will also target NUnit 3.10.1 (which will be consumed by projects that target Xamarin). All existing test project targets can use the latest version of NUnit, 3.17. It is becoming clear that the `Dependencies.props` file needs to be changed to a later place in the pipeline after the `TargetFramework` has been set so it can have conditional `PackageFramework` dependency versions set for specific target frameworks. Currently it is referenced by the root `Directory.Build.props` file, which is before target framework is specified. This would allow us to specify 3.10.1 for .NET Standard 2.x and 3.1.7 for everything else. I will need to check how difficult it may be to tie the output of `Console.WriteLine` to the output of `Xamarin`, although I wasn't planning on releasing the test runner I created along with Lucene.NET, it is just to verify compatibility with mobile platforms. ### Parallel Unit tests Sounds good in theory, but in Lucene.NET we are limited to running tests serially due to shared static members in the test framework. Changing this could be done, but would require some fairly extensive refactoring with how the codecs are loaded and breaking API changes. So, in effect we are gaining nothing from this NUnit "feature" except confusion about where the results are and even worse, limits that cause truncation of the output and/or crashes. [Here is a test that is crashing](https://github.com/apache/lucenenet/blob/ae13dc4dfe0b8a2d305b9f8f860ac0849a16ac80/src/Lucene.Net.Tests/Index/TestByteSlices.cs#L35-L44) when the buffer in VS is overloaded. ### VS Test Output "Copy Details" seems to have some finite limit. If the amount of text exceeds the limit, it is truncated and may not be very useful. Unfortunately, the Lucene tests were designed with an infinite amount of space to log into. I don't find the logging here particularly useful either. However, it is not just meant for the Lucene.NET team, it is meant for anyone that consumes the test framework - therefore, it should be set up in a reasonable way to make debugging easy for those who depend on it. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
