maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthew Adams <matt...@matthewadams.me>
Subject Re: maven-failsafe-plugin: what is it actually intended for?
Date Tue, 19 Nov 2013 00:56:23 GMT
Oops.  Yes, verify.


On Fri, Nov 15, 2013 at 12:49 AM, Vincent Latombe <vincent.latombe@gmail.com
> wrote:

> 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
> >
>



-- 
mailto:matthew@matthewadams.me <matthew@matthewadams.me>
skype:matthewadams12
googletalk:matthew@matthewadams.me
http://matthewadams.me
http://www.linkedin.com/in/matthewadams

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