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 <r...@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.lato...@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.lato...@gmail.com> >> >>> you mean 'verify', not 'validate' >>> >>> Vincent >>> >>> >>> 2013/11/14 Matthew Adams <matt...@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 <matt...@matthewadams.me >>>>> wrote: >>>> >>>>> On Wed, Nov 13, 2013 at 10:39 AM, Ron Wheeler < >>>>> rwhee...@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:matt...@matthewadams.me <matt...@matthewadams.me> >>>> skype:matthewadams12 >>>> googletalk:matt...@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-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
