On 11.08.2005 23:09:46 J.Pietschmann wrote: > Hi devs, > > in yet another attempt at getting back into FOP development I got > distracted again by question regarding cleanup and testcases.
Rubbing my hands.... :-) > - Do we still need the various .cvsignore files? No. Their content has been converted to SVN properties. > - build.xml > * Do we still need the htmldoc, pdfdoc and various html-* targets? > The html-* targets probably wont run anyway. I guess not. The build could instead call Forrest. In Barcode4J I have split a build-dist.xml off of the main build which is used to build documentation and the distribution. > * The "prepare-docs" target seems to be orphaned. Agreed. > * Why does the "package" target depend on "hyphenation-jar"? Probably a simple oversight. > * What's the purpose of "hyphenation-jar", anyway? To provide the default set of hyphenation patterns distributed with FOP that can be used instead of the one from OFFO? Not sure. Just realized that fop-hyph.jar is empty on my machine. Oops. > * Why is there a "compile-src" and an empty "compile"? We might have had additional steps in the past. Optimize away... > * Does anybody run the "test" target? I don't. Not stable enough. > - The README in /docs is outdated > - Much of the content in /docs seems to be obsolete too. Right. That's some left-over from the docs-refactoring. > - Shouldn't the java examples reuse FO/SVG/XML from the FO examples > directory rather than provide its own sample sources? Not necessarily. These are minimal files. Focus is on Java code. The stuff in FO examples are feature demos. > - Is the FOP servlet considered an example or rather an end user > application like the FOP CLI? IMO, it's an example which is only usable for people with very basic needs. I think it needs some additional work to become more generally usable. That's why I'm not 100% happy with its placement. Examples was not ideal, either. I don't even remember what I said back then when we moved to servlet, :-( but if I haven't changed my mind in the meantime I don't consider it an integral part of the FOP sources. The servlet must be easily found and is ideally easily customized and extended separately from the normal FOP source code, i.e. copy away a directory (with its own build) and start improving the servlet. Just an idea.... > - The /src/conf/web.xml for the FOP servlet seems to be a bit out of > place. E.g. the AWT viewer has its jarred-in resources locally stored. Shrug. > - Shouldn't the TestConverter.java and perhaps the RunTest.java files > be moved to the /test tree? Or, the other way around, move all the > Java files from /test into the /src/java subtree and keep only the > data files in /test? (I know it's custom to put JUnit test cases in > /test, but our /test contains a lot more machinery) But see further > below for more issues here. If anything, move it into test. Please let's not pile up more code under src. > - Which of the tests in /test/xml/bugtests et. al. are obsoleted by > the layoutengine test framework? Never checked. Bugtests may still have the use. At one point the layoutengine/testcases directory will become too crowded and we might want to separate feature tests from bug/regression tests. > - Which other test files are now obsolete? GenericFOPTestCase and > related sources seem to be candidates. Yep. As I always said, testing on hashes of the output files requires very careful work and is unstable and therefore unattractive. > - Should Keiron's test framework (TestConverter/RunTest) be considered > obsolete? Should tests which are not layoutengine tests be converted > to JUnit tests? (Well, probably...) I don't use TestConverter/RunTest. Too unstable for my taste. I consider this obsolete. Furthermore, I'm working on a visual testing framework so the renderers, can be tested, too. I think that is going to be more versatile. As much as possible should be JUnit tests, but not necessarily everything. The visual testing framework will at the beginning be not JUnit test, but only a batch converter which creates a simple (local) website where you can compare output. It's going to be closer to TestConvert/RunTest but we may eventually automate this stuff in a Solaris zone similar to what Forrest, Gump etc. have. > - How should an acceptable structure of the /test/resources subtree > look like? Good question. Ideas welcome. I created the images directory to place stuff I use in the layoutengine tests. > - Should we really test for invalid XML (see /test/errors)? In one way or another we should test how FOP reacts to invalid input. But it would need to be integrated into the JUnit tests so these tests are run by some people at least. I haven't done anything with these until now. > - How should Junit tests for proper handling of invalid input should > look like? - Checking if the right exceptions are thrown. - Checking if location information is available (and if it's right). - At one point I'd like error codes in all FOP-thrown exceptions which can be used to translate the error messages into the user language and so applications can better react to certain errors. When that is available the JUnit tests could check for the error codes, too. Jeremias Maerki
