lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "michael herndon (JIRA)" <>
Subject [Lucene.Net] [jira] [Created] (LUCENENET-435) Fix the test suite for Lucene.Net Core
Date Wed, 13 Jul 2011 17:06:59 GMT
Fix the test suite for Lucene.Net Core

                 Key: LUCENENET-435
             Project: Lucene.Net
          Issue Type: Task
          Components: Lucene.Net Test
    Affects Versions: Lucene.Net 2.9.4g
         Environment: all
            Reporter: michael herndon
            Assignee: michael herndon

 * There needs to be a running list of things to do/not to do with testing. I don't know if
this goes in a jira or do we keep a running list on the wiki or site for people to pick up
and  help with.  
 * Tests need to run on mono and not Fail (there is a good deal of failing tests on mono,
mostly due to the temp directory have the C:\ in the path).  
 * Assert.Throw<ExceptionType>() needs to be used instead of Try/Catch Assert.Fail.
 * File & Path combines to the temp directory need helper methods, 
     * e,g, having this in a hundred places is bad   new System.IO.FileInfo(System.IO.Path.Combine(Support.AppSettings.Get("tempDir",
""), "testIndex"));
 * We should still be testing deprecated methods, but we need to use #pragma warning disable/enable
0618  for testing those. otherwise compiler warnings are too numerous to be anywhere near
 * We should only be using deprecated methods in places where they are being explicitly tested,
other tests that need that functionality in order to validate those tests should be re factored
to use methods that are not deprecated.
 * Identify code that could be abstracted into test utility classes.   
 * Infrastructure Validation tests need to be made, anything that seems like infrastructure.
 e.g. does the temp directory exist, does the folders that the tests use inside the temp directory
exist, can we read/write to those folders. (if a ton of tests fail due to the file system,
we should be able to point out that it was due to permissions or missing folders, files, etc).

 * Identify what classes need an interface, abstract class or inherited in order to create
testing mocks. (once those classes are created, they should be documented in the wiki). 

** Asset.Throws needs to replace stuff like the following. We should also be checking the
messages for exceptions and make sure they make sense and can help users fix isses if the
exceptions are aimed at the library users.
				d = DateTools.StringToDate("97"); // no date
			catch (System.FormatException e)
				/* expected exception */

This message is automatically generated by JIRA.
For more information on JIRA, see:


View raw message