Mailing-List: contact lucene-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
Message-ID: <00b101c38b48$7771f8d0$2e81ba50@eamon>
From: "Mike Hogan" <me@mikehogan.net>
To: "Lucene Developers List" <lucene-dev@jakarta.apache.org>
References: <FB0AADB2-F735-11D7-B81C-000393A564E6@ehatchersolutions.com>
Subject: Re: [subscriptions] Re: Please make
 org.apache.lucene.index.IndexWriter non-final
Date: Sun, 5 Oct 2003 15:56:25 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

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: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org