lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: Problem: final modifier (e.g. Document) prevents Mocked Unit Tests
Date Fri, 01 Aug 2003 18:09:19 GMT
On Friday, August 1, 2003, at 12:11  PM, Vladimir Djuzhev wrote:
>> Yup, I use mocks myself.
>   Hello, brother in arms! ;)

Rock on!

>> If you can show a use case of where extensions are necessary beyond
> testing
>   Do you think this one reason is not enough? ;/
>   Well, I'll see what can I do with RAM/FS Directory, but
>   really: how do you think can I test the following logic
>   without using MockDocument and MockField?

With RAMDirectory, I don't see why you'd need to mock Document or 
Field.  You certainly still want to leverage all the analysis that 
Lucene is doing, right?

> ===================================
>             if( name.equals(Indexer.FIELD_RELATIVE_URL) ) {
>                 document.add(Field.Keyword(name,value.toString()));
>             } else if( name.equals(Indexer.FIELD_CREATED) ) {
> document.add(Field.Keyword(name,DateField.dateToString((Date)value)));
>             } else if( name.equals(Indexer.FIELD_TEXT) ) {
>                 document.add(Field.UnStored(name,value.toString()));
>             } else if( name.equals(Indexer.FIELD_CATEGORIES) ) {
>                 document.add(Field.Text(name,value.toString()));
>             } else {
>                 // dozen: yes, I know it matches prev line; I'm not 
> sure
> this default is right
>                 // so it's subject to change
>                 document.add(Field.Keyword(name,value.toString()));
>             }
> ===================================
>   In short: here I shall perform different actions depending on
>   keys and (not implemented yet) types of objects (f.ex, for Date's
>   I have to use dateToString()).
>   Can it be achived without Mocks (and not running actual tests)?

Are you just trying to test your logic of how a field name maps to 
either DateField, unstored field, text field, or keyword field?  If 
that is the case, then pull logic into a utility method that perhaps 
returns an identifier of what type of field to create, or perhaps have 
a method that returns a Field object handing it name and value, and 
then do tests on the Field object returned about how it is configured?

Even with a more rigid API like Lucene's (and final was used by design 
- why make something extensible if it doesn't need to be extended 
ever?), you can always refactor or isolate the rigidity somehow for 
testing purposes.  Perhaps not as picturesque as you'd like, but 
certainly whatever you're trying to test here can be separated a bit 
more somehow.


View raw message