I worked on starting to create an infrastructure for making the various unit test of GateIn easier to configure. Actually it is an attempt to fix several points that hurts us today: 1/ control the services that are used during the unit test : we had an issue a couple of weeks ago by a service declared in core component (in exo-jcr repo) that was declaring an hibernate service shadowing in some unit test the same service declared in GateIn. While it was fixed in core component (requiring a release only for that purpose), the fact to import all the configuration is pretty much an issue for several reasons (dependencies are not controlled, boot time is impacted) 2/ avoid to repeat the configuration for testing over and over. We want to achieve reusability and minimality when we write unit test for a module. For instance if a module requires a JCR repo and the organization service, we want: - not declare them locally unless a special configuration is required - share that configuration between module unit tests 3/ fix the absolute path required for several unit tests (not now, when effort will be achieved) For that matter I started the effort by providing a minimal set of code to reuse in unit test (namely the AbstractGateInTest class) that works by filtering the configuration loaded from the classpath by removing all configuration except the explicitly defined configuration. Configured is explicitly defined by annotating the unit test either with shared reusable configuration or with custom configuration found in the classpath (usually located in the test / resources of the module). The initial reusable module is the JCR module that when booted provides a repository with a unique workspace called "portal-test". For now only one module uses it and that is the component/common module. For other modules (like component/portal or component/ application-registry), there is a need for doing an organization module and that is not yet done. Note that each test component is a standalone maven module in order to express the classpath dependencies of the test component. I started to write things in the wiki on this page http://www.jboss.org/community/wiki/GateInPortalTestComponent I hope we can complete that effort soon and achieve the following: 1/ rationalized configuration 2/ not reuse portal configuration 3/ no more absolute path needed 4/ fast boot time for unit test providing a better productivity for developers cheers Julien

after more work on that topic, it seems that the gatein.checkout.dir is not necessary anymore. (It was required when some tests were using war file located resources such as configuration files. Those were taken in the runtime configuration of the portal). I removed the checkout dir necessity from maven, and for me everything looks fine, if something bad happens don't hesitate to rollback that last commit. On Dec 7, 2009, at 11:52 PM, Julien Viet wrote: > I have configured to use for now slf4j-simple. It used to be slf4j- > log4j (coming from the kernel and excluded via the > dependencyManagement section) but it's better for now an slf4j- > simple rather than an unconfigured slf4j-log4j. > > we probably need to define how logging should be performed for > testing and I suggest that we set the log level of info on the > console and have an additional file to contain all the logging for > further reference when debugging a test. > > On Dec 6, 2009, at 11:18 PM, Julien Viet wrote: > >> I worked on starting to create an infrastructure for making the >> various unit test of GateIn easier to configure. Actually it is an >> attempt to fix several points that hurts us today: >> >> 1/ control the services that are used during the unit test : we >> had an issue a couple of weeks ago by a service declared in core >> component (in exo-jcr repo) that was declaring an hibernate >> service shadowing in some unit test the same service declared in >> GateIn. While it was fixed in core component (requiring a release >> only for that purpose), the fact to import all the configuration >> is pretty much an issue for several reasons (dependencies are not >> controlled, boot time is impacted) >> >> 2/ avoid to repeat the configuration for testing over and over. We >> want to achieve reusability and minimality when we write unit test >> for a module. For instance if a module requires a JCR repo and the >> organization service, we want: >> - not declare them locally unless a special configuration is >> required >> - share that configuration between module unit tests >> >> 3/ fix the absolute path required for several unit tests (not now, >> when effort will be achieved) >> >> For that matter I started the effort by providing a minimal set of >> code to reuse in unit test (namely the AbstractGateInTest class) >> that works by filtering the configuration loaded from the >> classpath by removing all configuration except the explicitly >> defined configuration. Configured is explicitly defined by >> annotating the unit test either with shared reusable configuration >> or with custom configuration found in the classpath (usually >> located in the test / resources of the module). >> >> The initial reusable module is the JCR module that when booted >> provides a repository with a unique workspace called "portal- >> test". For now only one module uses it and that is the component/ >> common module. For other modules (like component/portal or >> component/application-registry), there is a need for doing an >> organization module and that is not yet done. >> >> Note that each test component is a standalone maven module in >> order to express the classpath dependencies of the test component. >> >> I started to write things in the wiki on this page http://www.jboss.org/community/wiki/GateInPortalTestComponent >> >> I hope we can complete that effort soon and achieve the following: >> >> 1/ rationalized configuration >> 2/ not reuse portal configuration >> 3/ no more absolute path needed >> 4/ fast boot time for unit test providing a better productivity >> for developers >> >> cheers >> >> Julien >