Re: [gatein-dev] GateIn portal component test infrastructure

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