[gatein-dev] GateIn portal component test infrastructure

[Julien Viet]

I have updated the component test to create a new directory for test  
data on each execution of maven.

It creates a dir "gateintest-xyz" in target directory.

The idea is to avoid to do mvn clean and save a bit of time.

That works only for tests that extends AbstractGateInTest and that  
have configuration that use the system property gatein.tmp.dir to save  
data.

On Dec 14, 2009, at 2:15 AM, Julien Viet wrote:

> 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
>>
>