Review tests for Lucene.Net assembly

Occasionally, tests are still being found with important lines that have been commented because the functionality didn’t exist at the time they were ported. Additionally, some test conditions have been changed from what they were in Java (although in some cases this is a necessary change due to a difference in platforms and in other cases it is a bug). We need some assurance that none of our green tests are false positives.

A line-by-line review would be best, but at the very least we should be checking that the implementations are complete and the test conditions are the same as in Java Lucene 4.8.0. Checking at the method level to ensure they all exist and have the right attributes has been completed already on Lucene.Net (core).

The tests in question need to be analyzed to ensure:

1. That the test conditions weren’t changed from what they were in Lucene (without some very good reason)
2. That none of the asserts or parts of the test setup were simply commented out to make the test pass rather than fixing the underlying problem
3. (for tests other than Lucene.Net (core)): The test methods/classes are not skipped in Lucene.NET unless they were skipped in Lucene or have some known problem

There may be other unforeseen issues with the tests (such as an incorrect translation of the line), as well, which is why a line-by-line comparison would be best.

Some Other Things to Look For

1. Missing [Test] attributes. Note that in Lucene tests are run by naming convention for any parameterless method named starting with test, but in .NET the attribute is required.
2. Formatting of arrays over multiple lines
3. Stripped comments which would provide needed context
4. Partially implemented classes/tests
5. Method calls such as Convert.ToString(int) that require an explicit CultureInfo.Invariant parameter to match Java
6. APIs that accept/return object that are using value types (boxing/unboxing)
7. APIs that require casting in order to use them, which is something we should strive to solve
8. APIs that accept/return non-generic collections, which we should strive to make generic

While it isn’t the most important part of the task, the tests are also the easiest place to spot usability issues with the API, so if any are discovered (that aren’t already marked LUCENENET TODO) we should open new issues for them as well.

The test projects that need review are:

• Lucene.Net.Tests._A-D
• Lucene.Net.Tests._E-I
• Lucene.Net.Tests._I-J
• Lucene.Net.Tests._J-S
• Lucene.Net.Tests._T-Z
• Lucene.Net.Tests.Classification (See #420)
• Lucene.Net.Tests.Codecs (See #425)
• Lucene.Net.Tests.Expressions (See #435)
• Lucene.Net.Tests.Facet (See #411)
• Lucene.Net.Tests.Join (See #414)
• Lucene.Net.Tests.Queries (See #432)

JIRA link - [LUCENENET-632] created by nightowl888

[NightOwl888]

@rclabo

That’s great. However, IMO it might make sense to hold off on reviewing Lucene.Net tests until after we have converted the exceptions and catch blocks in #446.

If you have already started, just continue to the end of the tests in that assembly, but we certainly should wait on the index reader/writer tests until after this is done. There may also be issues that are resolved by #446 in codecs.

[rclabo]

I’ll review Lucene.Net.Tests.Expressions