There currently are no true JUnit tests in Lucene's codebase that use an FSDirectory. There are some classes in the src/test directory (*Test.java, whereas JUnit tests are Test*.java) that are Java main routines that use FSDirectory and are not run automatically. It would be nice to convert the useful bits of these into JUnit tests that either use RAMDirectory (if the directory implementation is irrelevant) or FSDirectory (when file system directory tests are needed).
We want to be sure that any such test cases using FSDirectory work well with Ant, and I will be more than happy to assist with this. Perhaps we set up an Ant property, test.index.dir, and pass that as a system property into the test cases. We could make a FSDirectoryTestCase abstract base class that we extend for tests needing a file system directory. Test cases themselves should rewrite the entire index to have a known starting point.
I'll go ahead and put in some infrastructure with the above mentioned items and check it. Feel free to take the ball and run with it from here.
As for known datasets - since no tests uses a file system index, none use a known dataset. Doug mentioned we should add some type of version information to the Lucene index so backwards compatible issues can be dealt with. Having a set of .zip files from different versions of Lucene seems like a great way to accomplish this.
Erik
On Friday, September 19, 2003, at 04:21 PM, Dmitry Serebrennikov wrote:
I'm trying to setup a JUnit test case that needs a file path in order to create an FSDirectory. (RAMDirectory is ok for some things, but I'd like to verify that the files are written correctly and can be read on subsequent runs of the program). Does Lucene have any standard policy for doing this in test cases? For example, I've seen people passing these kinds of things as System.properties. It can also be done relative to a working dir. Are there any test cases that already do this?
Also, are there test cases that have pre-built datasets that they start with. For example, a test case that verifies backward compatibility could start by reading an index directory created by a previous version. One solution I've seen to this is to have a set of zip files checked into CVS that contain various test data sets. A test case then starts off by expanding one of these into some pre-determined directory and proceeds from there. Has anything like this been done before for Lucene?
Thanks. Dmitry.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
