karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Further itest speed improvements
Date Sun, 27 Oct 2013 12:48:20 GMT
Hi guys,

I'm with ya' that a nightly with deploy should be sufficient.
Regarding the PerSuite / other Speed enhancements I'm not against but
we'd need to be very cautions that we don't have side-effects of this.
That's why I usually prefer to have the perTest fork and/or annotation on
the UnitTests.
It just makes sure you work on a clean container (just like you would work
on a clean database ;) )
I think at that point we just need to "bite that bullet" and keep to those
longer running tests.


regards, Achim



2013/10/27 Jean-Baptiste Onofré <jb@nanthrax.net>

> Hi Christian,
>
> It's what I said in my previous e-mail: if possible, I would like to avoid
> a job dedicated to itests. If there are no other ways, we will do like this.
>
> For the PerSuite, you have an option in Pax Exam to reuse an existing
> container. Let me try with that.
>
> Regards
> JB
>
>
> On 10/27/2013 10:35 AM, Christian Schneider wrote:
>
>> Hi JB,
>>
>> I created an itest build here:
>> https://builds.apache.org/**view/H-L/view/Karaf/job/Karaf-**itests/<https://builds.apache.org/view/H-L/view/Karaf/job/Karaf-itests/>
>>
>> You can reuse it or delete it when you create a new build.
>>
>> About the PerSuite tests. I have experimented a bit. In eclipse I was
>> able to run most of the karaf tests successfully in PerSuite mode and
>> they are really extremely fast. Unfortunately I was not able to make
>> them work with maven. In maven the karaf container was always created
>> for each test class. I think it is related to the fork mode of surefire.
>> By default it seems to start a fresh process for each test class. When I
>> changed forkCount to 0 none of the tests work. So the results of my
>> experiments is that it has a lot of potential but currently does not
>> work correctly.
>>
>> Christian
>>
>> Am 27.10.2013 07:49, schrieb Jean-Baptiste Onofré:
>>
>>> Hi Christian,
>>>
>>> On 10/26/2013 09:28 PM, Christian Schneider wrote:
>>>
>>>> On 26.10.2013 21:14, Jean-Baptiste Onofré wrote:
>>>>
>>>>> 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.
>>>>>
>>>> I did not want to have a build without itests. The itests are fast
>>>> enough to run in both builds. I wanted one build with itests after each
>>>> commit and one build with itests and deploy nightly. The problem
>>>> currently seems to be the deploy it takes much longer than the tests.
>>>>
>>> Catcha, so build without deploy after scm poll, and deploy only for
>>> nightly builds ? I can do that.
>>>
>>>  - For the PerClass test on feature, I'm agree.
>>>>> - Not sure I follow you for the PerSuite. What do you mean ?
>>>>>
>>>> PerSuite will start karaf only once and run several test classes on it.
>>>>
>>> Catcha, you mean reuse the same Karaf container for all itests. We
>>> just have to be careful that one itest doesn't impact another. I have
>>> issues like this when I implemented itests.
>>>
>>> Regards
>>> JB
>>>
>>>
>>>> Christian
>>>>
>>>>
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home>
Commiter & Project Lead
blog <http://notizblog.nierbeck.de/>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message