Investigate Slow Tests in Lucene.Net.Util Namespace about lucenenet HOT 3 CLOSED

I believe NUnit should have an overload for numeric types but when comparing type long this seems to take a very long time to resolve. Using an overload a == b seems to result in much faster performance. The same is true for byte comparison.

This as been added to the Assert.cs file which overloads AreEqual for long and byte

from lucenenet.

Tests in T-U seem to have been resolved where there is the most delay.
Adding the following line will force the tests to use the overloaded methods.

using Assert = Lucene.Net.TestFramework.Assert;

assertEquals in LuceneTestCase has also been modified to use the same equivalence checks

from lucenenet.

@bongohrtech - Good find. There are several tests that are passing value types through Assert.AreEqual(object, object) in a tight loop, causing lots of box/unbox operations. And of course, this problem isn't limited to the Lucene.Net.Util namespace.

I have confirmed that changing this gets both T-U and U-Z projects to run in under 3.5 minutes, which were more like 11 minutes before.

We should aim to apply this fix on all of the projects starting with the longest running ones:

• Lucene.Net.Tests._E-I
• Lucene.Net.Tests.Analysis.Common
• Lucene.Net.Tests.Codecs
• Lucene.Net.Tests._A-D
• Lucene.Net.Tests._J-S

We can probably also consolidate some of the 5 Lucene.Net test projects that were broken up, which should help to speed up the overall time in Azure DevOps.

from lucenenet.