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

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