Jeremias Maerki wrote: > On 18.04.2008 12:48:53 Vincent Hennebert wrote: >> Hi, >> >> A few comments: >> >> - some time ago I created a BreakUtil class in the o.a.f.util package. >> I think this class and KeepUtil should be put in the same place. >> Perhaps we could even merge them into a unique KeepsAndBreaksUtil >> class. I don’t really know what the best place would be. I put it in >> o.a.f.util because it already contains all sorts of utility classes, >> but o.a.f.layoutmgr would also make sense. WDYT? > > Whatever.
I let you choose, but please take care of this. >> - it would be better to create the testcases such that the rendering >> will become wrong if the feature is broken. For example, put the block >> at the bottom of the page, such that it gets deferred to the next page >> if keep is working, and split over 2 pages if keep is broken. Exactly >> like you did in block_keep-together_integers_1.xml. >> There are 2 reasons for this: >> - just because the element list looks ok doesn’t ensure that the >> rendering will be fine. Actually a recent post on fop-users [1] >> shows that. > > We've had the other case, too: Rendering looked fine but the element > list was wrong and lead to bad break decisions. I'm not sure if your > example is a good one. At least it shows that testing only one thing is not enough. >> - if the generation of Knuth elements is changed somehow, all the >> testcases must be adapted accordingly. I had to do that several >> times when working on tables in the past months, and this is really >> painful. Tests on Knuth elements should be reserved for special >> situations IMO. > > I'm doing unit testing here, or at least as "unit" testing as possible. > What you're talking about is component testing and larger. I want to > make sure that the element list is correct and I trust that the breaking > algorithm does the right thing because it is already tested elsewhere. I > completely disagree that element list test should be reserved for > special situations. Or else this is exactly such a special situation for > me. Fair enough. Vincent -- Vincent Hennebert Anyware Technologies http://people.apache.org/~vhennebert http://www.anyware-tech.com Apache FOP Committer FOP Development/Consulting
