lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <>
Subject Re: Fwd: Recomended strategy for perform test cases for a new port
Date Thu, 17 Mar 2005 15:11:43 GMT

> I finish the main (and boring!) part of port Lucene to Delphi
> (
> So, I build some test cases and rigth now I pass test cases for:
> - BitVector
> - Field
> - DateField
> - Document
> - Number
> - PriorityQueue
> - StringHelper
> - Token
> - Analyzers (Simple,Null,Stop,Perfield)
> I want to know, from your experience, how go from here? I have a
> "compile" version but really not work.
> What classes/branch must pass/work rigth before the others? What path
> follow, how be more productive?
> I want to know what is the basic strategy to build the testcases (ie:
> Test first this, then move to that, etc...). My first inclination is
> get a chart of the code in  UML and go for each branch. However,
> because some clases are interacting to others, this can be very hard
> to do. I prefer a strategy where I can go for the basic stuff and
> leave complex classes for later, so i can reach beta more quickly.

My experience is probably a bit different, since Lucene4C isn't just 
recreating the various classes in the Java version, but what I've done 
is started with the lowest level APIs for reading files from disk, 
tested them, then built on top of them code for reading Lucene's 
specific file formats, tested them, then built the code for using that 
to run rudimentary searches, and tested that.

Honestly, just going through and making a direct port of all the classes 
seems counterproductive.  Now you're at the point where you've got all 
this code, and have no idea what parts of it work and what don't.  I'd 
suggest finding the lowest level bits and pieces and building your tests 
there, working your way up.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message