lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [lucenenet] NightOwl888 opened a new issue #306: Make assertions into a 1st class feature in the test framework
Date Tue, 07 Jul 2020 12:04:12 GMT

NightOwl888 opened a new issue #306:

   We recently discovered that the assertions provided by NUnit do not provide any support
for primitive types and in those cases will default to `object` which causes boxing/unboxing
when doing assertions. This can be a huge drain on performance when this operation is done
in a tight loop. 
   It is clear that end users will likely run into similar issues with testing that we did.
While we have addressed the problem, we did so in 2 assertions types that are both internal.
We need to create a public API for assertions that end users of the test framework can use.
   - Missing overloads need to be added to support all of the operations that NUnit does
   - Custom asserts that we created need to be expanded to include all primitive types
   - A logical way to make these asserts "native" in `LuceneTestCase` and all of its subclasses
needs to be devised
   In Lucene, `LuceneTestCase` simply subclassed `Assert`. However, due to a difference in
naming conventions between NUnit and JUnit, this would seem odd. For example, instead of `AssertEquals`,
the NUnit team named their method `AreEqual`. While this isn't such a problem, it would be
inconsistent with all of the other custom assertions in the test framework (i.e. `AssertAnalyzesTo`).
   In addition, API documentation should be provided for each of the assertions.

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:

View raw message