maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mirko Friedenhagen <mfriedenha...@gmail.com>
Subject Re: maven-failsafe-plugin: what is it actually intended for?
Date Fri, 15 Nov 2013 21:13:33 GMT
Almost same here, Russel. I always execute `mvn test` on my
workstation, where these should be executed in less than a minute and
let failsafe via `mvn deploy` (which comes after `verify`) in our CI
system (for the Jenkins jobConfigHistory-plugin this takes about 10
minutes). I do not use failsafe:verify because Jenkins is able to set
the build to unstable when integration tests fail. So a breaking unit
test fails the build (Red in Jenkins) and a breaking integration test
sets the build to unstable.

I even would defer tests involving spring to the integration test
phase, as spring will delay results as well :-).
I prefer tests which create and start a container (e.g. Tomcat) as
well as integration tests.

Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/ (http://osrc.dfm.io/mfriedenhagen)
https://bitbucket.org/mfriedenhagen/


On Fri, Nov 15, 2013 at 2:31 PM, Russell Gold <russ@gold-family.us> wrote:
> It appears that there are multiple use cases for failsafe. I tend to use it for slow
tests that don’t necessarily need to pass at the moment, but for which I want to know the
percentage passing. Accordingly, I bind the integration-test goal but NOT the verify goal.
>
> On Nov 15, 2013, at 1:57 AM, Vincent Latombe <vincent.latombe@gmail.com> wrote:
>
>> maven-failsafe-plugin implies some specific steps are required *before*
>> (pre-integration-test) and *after* (post-integration-test) the test
>> execution, which allows to do fire up a container then turn it off after
>> the tests (for example).
>>
>> Then, only after these, the test results are evaluated during 'verify'
>> phase and will fail the build if needed.
>>
>> This is unlike maven-surefire-plugin, that performs both the tests
>> execution and verification in the same step, which prevents you from doing
>> any kind of cleanup outside of test execution.
>>
>> So, using failsafe or surefire boils down to a single question : do you
>> need to perform any set up/teardown outside of the test execution
>> framework? If yes, use failsafe, if no, use surefire
>>
>> Cheers,
>>
>> Vincent
>>
>> Vincent
>>
>>
>> 2013/11/15 Vincent Latombe <vincent.latombe@gmail.com>
>>
>>> you mean 'verify', not 'validate'
>>>
>>> Vincent
>>>
>>>
>>> 2013/11/14 Matthew Adams <matthew@matthewadams.me>
>>>
>>>> Here's a bit less philosophical, more practical description of Surefire v.
>>>> Failsafe.
>>>>
>>>> Remember that if you use the maven-surefire-plugin, it's going to execute
>>>> during the Maven "test" phase by default, and fail the build on errors
>>>> _during that phase_ if any tests fail.
>>>>
>>>> The maven-failsafe-plugin executes during Maven's "integration-test" and
>>>> "validate" phases.  *Remember to specify both goals!*  See
>>>> http://maven.apache.org/surefire/maven-failsafe-plugin/usage.html and
>>>> notice that _both_ goals, integration-test & validate, need to be
>>>> specified.  This allows the integration tests to execute & possibly fail
>>>> without _immediately_ failing the build.  The failing of the build happens
>>>> via maven-failsafe-plugin during the validate phase, so that other plugins
>>>> can clean things up during Maven's "post-integration-test" phase, which
>>>> precedes "validate".
>>>>
>>>> HTH,
>>>> Matthew
>>>>
>>>>
>>>> On Thu, Nov 14, 2013 at 4:30 PM, Matthew Adams <matthew@matthewadams.me
>>>>> wrote:
>>>>
>>>>> On Wed, Nov 13, 2013 at 10:39 AM, Ron Wheeler <
>>>>> rwheeler@artifact-software.com> wrote:
>>>>>
>>>>>> On 13/11/2013 11:16 AM, Matthew Adams wrote:
>>>>>>
>>>>>>> I don't think timing should be the heuristic here.  The fact
that unit
>>>>>>> tests take less is a result of the fact that what you're testing,
aka
>>>> the
>>>>>>> "unit", tends to be small.  After all, a unit test should test
a
>>>> "unit".
>>>>>>>
>>>>>> So what is your definition?
>>>>>>
>>>>> "A unit test is test code that tests a unit in isolation."  It's
>>>>> intentionally ambiguous, because a unit is relative and may differ.
>>>>>
>>>>>
>>>>>>
>>>>>>> An integration test, then, if I were defining it strictly, would
be
>>>>>>> anything that's not a unit test.  In practice, this usually means
>>>>>>> replacing
>>>>>>> any mocks and/or stubs in your unit tests with the real
>>>> implementations,
>>>>>>> plus using any other supporting infrastructure, like databases,
>>>>>>> dependency
>>>>>>> injection contexts, etc.
>>>>>>>
>>>>>> Not sure that this is true for all integration tests. You may be
able
>>>> to
>>>>>> test the integration of two projects (a web service and a database
>>>> access
>>>>>> layer) while still using mocks and stubs (mock of a database
>>>> persistence
>>>>>> layer).
>>>>>> People frequently test with Jetty when the final project will run
on
>>>>>> Tomcat.
>>>>>> It all depends on what part of the system integration is being tested.
>>>>>>
>>>>>
>>>>> I didn't say it had to be what's used in production.  The key difference
>>>>> is that you're using _something_, in addition to the unit.
>>>>>
>>>>> -matthew
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> mailto:matthew@matthewadams.me <matthew@matthewadams.me>
>>>> skype:matthewadams12
>>>> googletalk:matthew@matthewadams.me
>>>> http://matthewadams.me
>>>> http://www.linkedin.com/in/matthewadams
>>>>
>>>
>>>
>
> -----------------
> Author, Getting Started with Apache Maven <http://www.packtpub.com/getting-started-with-apache-maven/video>
>
> Come read my webnovel, Take a Lemon <http://www.takealemon.com>,
> and listen to the Misfile radio play <http://www.fuzzyfacetheater.com/misfile/>!
>
>
>
>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Mime
View raw message