Mailing-List: contact users-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Users List" <users@maven.apache.org>
Received-SPF: pass (athena.apache.org: local policy includes SPF record at
 spf.trusted-forwarder.org)
MIME-Version: 1.0
In-Reply-To: 
 <CAGZB7Rh_fdWAdXq0BDnnkWJhzFtL1wzp54fdHE6w1+u3CTUWjw@mail.gmail.com>
References: 
 <CAMH6+axEvCoHXw0PiZAzvb+CrzyAMG3dyrS2r+_HVrzsQLHu2g@mail.gmail.com>
 <CA+nPnMwa-WXS6s-mKsyj9-L5rLAWz48kC1wQWGNA5J5UWU189A@mail.gmail.com>
 <CAGZB7RgxYGw7rnoo8Kauf=W3XPNYZW24BFXAjuXShv04qWaPbg@mail.gmail.com>
 <5283AB53.5050602@artifact-software.com>
 <CAGZB7Rh_fdWAdXq0BDnnkWJhzFtL1wzp54fdHE6w1+u3CTUWjw@mail.gmail.com>
From: Matthew Adams <matthew@matthewadams.me>
Date: Thu, 14 Nov 2013 16:38:48 -0600
Message-ID: 
 <CAGZB7RjwTxakJEBhVxGBL0h_PB5gg3qgWf8p1EiW93pKfk1fDw@mail.gmail.com>
Subject: Re: maven-failsafe-plugin: what is it actually intended for?
To: Maven Users List <users@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2b998fd381b04eb2abf52

--001a11c2b998fd381b04eb2abf52
Content-Type: text/plain; charset=ISO-8859-1

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

--001a11c2b998fd381b04eb2abf52--