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 <[EMAIL PROTECTED]> 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
