+1 totally on unit tests. This is the chief path to quality and not breaking things or having them break silently.
-andy Paul Hammant wrote: > Nicola, > > My only comment in addition to that of the others is that make sure you > write unit tests for each component as you refactor. At work we have > written a an AbstractPhoenixTestCase that pretends to be Pheonix for > testing of a component. Now, that is just for Phoenix and perhaps you > default impl for FOP should be a home-grown container tightly coupled to > FOP and in FOP's codebase. Either way, if it is lifecycle aware, it > will be similar to the AbstractPhoenixTestCase we wrote (but can't > submit to Apache CVS). With Unit testing, or more accurately > integration testing, you will be able to prove that as you refactor, > things continue to work. It will help the bravery aspect drawn from XP. > > Good luck & will love to see the product. > > - Paul > > > >> I'm doing some work on Avalonizing FOP, as it has been decided it's >> the right way. >> >> We are using already LogEnabled, and now it's time for Configuration, >> but most important of all, usage of the SourceResolver. >> >> Now, I'm dealing with a problem I already had with POI (we want to >> avalonize it too probably). >> >> When we have big object pacakge structures and classes, it becomes >> somewhat impractical to use IoC. >> >> For example, in POI there are tons of classes that represent portions >> of the OLE2 file format. >> Shall I have all of these become container-components? >> >> Or in FOP: there needs to be an ImageFactoryService, but the problem >> is that it needs to be used by projects deep in the call stack. >> >> How can I make these components serviceable? >> Should I? >> >> It seems that when the model becomes too finegrained, the Avalon >> patterns become difficult to use. >> >> Comments, ideas? >> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
