-
1. Re: Slow integration testing suite based on SeamTest - impro
gavin.king May 24, 2007 9:49 AM (in response to andreigh.ts)No, no especially good reason....
-
2. Re: Slow integration testing suite based on SeamTest - impro
andreigh.ts May 24, 2007 10:13 AM (in response to andreigh.ts)Looking in the source code for SeamTest.init() I see that it creates and initializes a servletContext and also creates conversationViewRootAttributes.
I was thinking that recreating servletContext and conversationViewRootAttributes might be nedded in order to clear some context variables (that was set up during each test) - so that we can have a clean state of the container before each test.
In this case maybe this functionality should be refactored out into the SeamTest.begin() method (which runs before each test method)? -
3. Re: Slow integration testing suite based on SeamTest - impro
dmitriy.lapko Aug 9, 2007 9:57 AM (in response to andreigh.ts)Are there any good news according these question?
It looks like before each test class in a test suite SeamTest.init() method is called, which doesn't start JBossEmbedded server if it is already started (that is good :) ) but each time initializes JBossSeam - again scans all jars for new components as something could be changed since last scan and so on...
So, may be it would be good to run SeamTest.init only once in a suite? -
4. Re: Slow integration testing suite based on SeamTest - impro
pmuir Aug 9, 2007 10:00 AM (in response to andreigh.ts)Please open a JIRA feature request for this.
-
5. Re: Slow integration testing suite based on SeamTest - impro
dmitriy.lapko Aug 9, 2007 10:44 AM (in response to andreigh.ts)Ok, created:
http://jira.jboss.org/jira/browse/JBSEAM-1779
But may be it will need deep refactoring in BaseSeamTest - if you will change just annotation@BeforeClass @Override public void init() throws Exception { super.init(); }
to@BeforeSuite @Override public void init() throws Exception { super.init(); }
it will not work - each class which extends SeamTest should be initialized separately...
So, now it seems that the easiest optimization can be to put all tests inside one test class.