lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alessio Pace" <>
Subject Re: Unit testing: Hits not implementing an interface and being final
Date Mon, 03 Jul 2006 14:38:36 GMT
thanks Erick for the answer.

The problem is that I am using Lucene through the Hibernate support, to map
trasparently Java domain entities to a file system Lucene index (no support
for a RAM Index at the moment, as far as I saw).

So some of my unit tests (which collaborate at some level with Lucene
functionalities) are a little slow because they all write to disk (and the
index is destroyed and recreated in each test class, to be self contained).

But anyway, they require me to set up an index, populate it, make a search
on it, just to have a bunch of Hits, even when what I have to test is not
integration with the inner content of the Hits object (I don't care if it is
"real" or a wrong search result, I just need it, so I wanted to subclass or
mock it).

And yes, I do value as well integration testing, but sometimes I prefer to
do just unit testing, so that I can easily detect how far from the bug I am

Thanks again, regards,

Alessio Pace.

On 7/3/06, Erick Erickson <> wrote:
> Don't know if this helps or hurts, but my approach for unit tests was to
> implement an index in a RAMdir for each test, index enough documents for
> my
> tests that I could strictly control and just do searches, man...
> True, the weakness was that the data sets are very small, and this more of
> a
> "black box" test than one might want. I suppose one could argue that since
> I
> wasn't actually looking at a disk file, I wasn't testing a major portion
> of
> the system. But it sure caught a bunch of my programming errors <G>....
> I had to do some fancy dancing to build an infrastructure that allowed my
> tests to index from a "semi-real" document characteristic of my problem
> space, which allowed me to have the indexing code in the loop as well...
> In essence, I forwent (what is the past tense of forgo anyway?) mock
> objects
> in favor of real objects and contrived a test that went fast enough that I
> didn't need to deal with mock objects and was self-contained.
> I had to make sure my search interface took a searcher object (a Dirctory
> would do), but that wasn't hard..
> Warning: I'm not the most experienced unit tester in the world <G>, but it
> seems to me that the fewer mock objects in the system, the fewer
> disconnects
> there are between what you think you are testing and what you are really
> testing, so I favor real objects over mock objects when it's reasonably
> straight-forward.
> GIven that I know nothing about your problem space, though, this may be a
> totally useless approach <G>....
> Best
> Erick

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message