You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Vladimir Djuzhev <do...@dataart.com> on 2003/08/01 15:22:58 UTC
Problem: final modifier (e.g. Document) prevents Mocked Unit Tests
ehlo.
We are developing a large corporate site, and decided to
integrate Lucene as search engine. Everything goes fine,
until we go into writing unit tests.
We heavily use Mocks for unit tests. It would be especially
useful for Lucene since any test performing indexing over
real data would take unappropriate time.
For those who do not familiar with the concept, I'll explain
briefly how the Mocks work: you disconnect object under test
from all it's links by replacing all links (member objects,
passing parameters etc) with objects that has the same (sub)type
as unlinked object, but are really configurable fake of it. Now
you can test the logic of the object with no interference and
much faster (orders of magnitute in execution speed! It's valueable
when you run UTs ten or twenty times a day!).
Ex:
// dozen: unlinked version of Crawler for tests
public static class MockedCrawler extends Crawler {
public MockedCrawler(String baseIndexDir, List indexers) {
super(baseIndexDir, indexers);
}
// overwrite real method to return Mock and configure it
protected IndexBuilder getIndexBuilder(boolean odd) {
MockIndexBuilder mib = new MockIndexBuilder(".");
mib.expectBegin();
mib.setAddDummy();
mib.expectEnd();
return mib;
}
}
For more information see http://mockobjects.com, there are
a lot of documentations and links to Mock generators.
The only way to make Mock to be of the same class as original
is to inherite from the original. That's what is impossible with the
current Lucene -- a lot of classes has final, a lot of methods has
final too. Right now I would like to mock IndexWriter, Document
and Field to test my IndexBuilder logic, but I can't. Sad.
Personally, I misbelief in final modifier. When someone extends
the class he shall know what he does, and if he does something
bad, it's his own fault. But making code untestable brings much
more danger, IMHO.
May I ask Lucene development team to remove final modifiers from
the code? ;)
dozen
Re: Problem: final modifier (e.g. Document) prevents Mocked Unit Tests
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
On Friday, August 1, 2003, at 09:22 AM, Vladimir Djuzhev wrote:
> We are developing a large corporate site, and decided to
> integrate Lucene as search engine. Everything goes fine,
> until we go into writing unit tests.
Have you tried using RAMDirectory rather than FSDirectory for your
index during testing?
> We heavily use Mocks for unit tests. It would be especially
> useful for Lucene since any test performing indexing over
> real data would take unappropriate time.
Yup, I use mocks myself.
> // dozen: unlinked version of Crawler for tests
> public static class MockedCrawler extends Crawler {
>
> public MockedCrawler(String baseIndexDir, List indexers) {
> super(baseIndexDir, indexers);
> }
I'd recommend you do a bit of inversion here, and have the outside
world control the implementation of Directory that is used. In
production, use FSDirectory. In testing use RAMDirectory. Refactoring
is par for the course here, and will likely imply changes to your code
- but that is what doing mock is all about - better design while
testing too! :)
> May I ask Lucene development team to remove final modifiers from
> the code? ;)
I disagree with this request, even to the point of -1. If you can show
a use case of where extensions are necessary beyond testing then it
would be considered, but I suspect you can refactor your code to use a
RAMDirectory for testing purposes.
Erik
Re: Problem: final modifier (e.g. Document) prevents Mocked Unit Tests
Posted by Erik Hatcher <li...@ehatchersolutions.com>.
On Friday, August 1, 2003, at 09:22 AM, Vladimir Djuzhev wrote:
> We are developing a large corporate site, and decided to
> integrate Lucene as search engine. Everything goes fine,
> until we go into writing unit tests.
Have you tried using RAMDirectory rather than FSDirectory for your
index during testing?
> We heavily use Mocks for unit tests. It would be especially
> useful for Lucene since any test performing indexing over
> real data would take unappropriate time.
Yup, I use mocks myself.
> // dozen: unlinked version of Crawler for tests
> public static class MockedCrawler extends Crawler {
>
> public MockedCrawler(String baseIndexDir, List indexers) {
> super(baseIndexDir, indexers);
> }
I'd recommend you do a bit of inversion here, and have the outside
world control the implementation of Directory that is used. In
production, use FSDirectory. In testing use RAMDirectory. Refactoring
is par for the course here, and will likely imply changes to your code
- but that is what doing mock is all about - better design while
testing too! :)
> May I ask Lucene development team to remove final modifiers from
> the code? ;)
I disagree with this request, even to the point of -1. If you can show
a use case of where extensions are necessary beyond testing then it
would be considered, but I suspect you can refactor your code to use a
RAMDirectory for testing purposes.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org