Hi Christian,
- If you mean create two job in Jenkins, I disagree. I would prefer to
work with profiles. More over, it makes sense to tight the itest on the
artifacts that we just built before. Maybe we can have to target on
Jenkins: one with the itest profile, one without the itest profile. The
trigger for the full build (including itest) is every night, the build
without itest is at scm polling.
- For the PerClass test on feature, I'm agree.
- Not sure I follow you for the PerSuite. What do you mean ?
Regards
JB
On 10/26/2013 08:51 PM, Christian Schneider wrote:
I would like to discuss some ideas to further speed up our itests.
Ideas:
- Split our jenkins builds into itest and deploy builds: On a local
machine the itest build finishs now in about 10 minutes. On jenkins the
build still takes over 40 minutes. Most of the time is spent on doing
the deploy part. So I propose to have two builds for each branch. One
itest build for fast developer feedback that runs after each commit and
one deploy build to keep the snapshots current that only runs once per day.
- Use PerClass for the feature tests and uninstall each feature before
the next test method runs. This brings the full build down to 5 minutes
on my machine. It works quite well. I will commit this if the tests are
stable on my machine.
- Use PerSuite for all non destructive tests (basically all tests that
should not change the karaf instance they run in). Pax exam now allows
to start the container only once for a whole suite of tests. We probably
need to move these tests in a separate maven project. This should
further speed up the tests quite a lot as most of our tests are non
destructive. I will have to do some more tests about this.
So what do you think?
Christian
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
