Unit testing: Hits not implementing an interface and being final

[Alessio Pace <al...@gmail.com>]

Hi,

I wanted just to share my issues with unit testing a component collaborating
with a Hits object.

The scenario is: I have a web page pagination component (say, it shows N
results per page) over the Hits results found in the Lucene index.

I want to test the pagination itselft, so I would like to provide it with a
stub or mock Hits implementation. The problem is that Hits does not
implement and interface, is final and has no public constructor (I am using
Lucene 1.4.3, but the latest 2.x seems to be the same, which prevents me
from subclassing it or mocking it (with EasyMock2 for example).

So my solution would be to change my component collaborator type from Hits
to a MyHits interface, which has a MyHitsImpl that works by delegation on a
concrete Hits object..

Any thoughts about it?

Best regards,

-- 
Alessio Pace.
http://www.jroller.com/page/alessiopace

Re: Unit testing: Hits not implementing an interface and being final

[Alessio Pace <al...@gmail.com>]

Hi,
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.
http://www.jroller.com/page/alessiopace

On 7/3/06, Erick Erickson <er...@gmail.com> 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
>
>

Re: Unit testing: Hits not implementing an interface and being final

[Erick Erickson <er...@gmail.com>]

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