Erik,
> Mike,
>
> I disagree with your request to change things just for testing
> purposes. There are ways to test most (if not all) of Lucene without
> having to affect method/class access levels. As big as I am into
> testing, I'm also big into using the right design for the right job.
> In the case of Lucene, 'final' is used liberally as well as other
> non-public access levels.
>
> Could you give us an example of what you're trying to test and how
> you're wishing you could go about it so that we could perhaps offer
> alternatives?
I am trying to test this:
public void index(String componentId, String componentDescription) throws
SearchService.Exception {
IndexWriter writer = null;
try {
writer = new IndexWriter(INDEX_FILE_PATH, new
StandardAnalyzer(), !indexExists());
final Document document = new Document();
document.add(Field.Text("id", componentId));
document.add(Field.Text("contents", componentDescription));
writer.addDocument(document);
writer.optimize();
writer.close();
} catch (IOException e) {
throw new SearchService.Exception("Exception updating Lucene
index", e);
}
}
I want to do it without a dependency on the file system. So I want a mock
IndexWriter that does what I configure it to, sometimes throwing an
IOException, some times not, and always storing the Document passed to it,
so I can verify() the document is as it should be.
> Look at Lucene's current codebase. I've added a couple of mock objects
> recently to test various things - maybe that could give you some ideas?
I am not trying to unit test Lucene. I am trying to unit test an
application of Lucene.
What ya reckon?
Thanks,
Mike.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
