Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 21255 invoked from network); 6 Jun 2006 05:54:05 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jun 2006 05:54:05 -0000 Received: (qmail 40785 invoked by uid 500); 6 Jun 2006 05:54:02 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 40740 invoked by uid 500); 6 Jun 2006 05:54:02 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 40729 invoked by uid 99); 6 Jun 2006 05:54:02 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jun 2006 22:54:02 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of craigmcc@gmail.com designates 64.233.184.237 as permitted sender) Received: from [64.233.184.237] (HELO wr-out-0506.google.com) (64.233.184.237) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 05 Jun 2006 22:54:01 -0700 Received: by wr-out-0506.google.com with SMTP id i21so1345717wra for ; Mon, 05 Jun 2006 22:53:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=KVexajVlAtpW6T/7XsYjeBSSWMkDK8tf+80Ek7ckrQhJpAYdDjNvcP+T2Ud1JNZrFTa90MBdXjQb3TMSiFTOeN6O1UnO3AhDwfCc3ox9fyk+72NlejC0yWtbNc+RGuXvAiJNCTIOvSFJwuqDLVi6/7xLTUKEv2OerRWR2YKANaE= Received: by 10.64.83.10 with SMTP id g10mr220872qbb; Mon, 05 Jun 2006 22:53:40 -0700 (PDT) Received: by 10.64.178.2 with HTTP; Mon, 5 Jun 2006 22:53:40 -0700 (PDT) Message-ID: Date: Mon, 5 Jun 2006 22:53:40 -0700 From: "Craig McClanahan" Sender: craigmcc@gmail.com To: "Struts Developers List" Subject: Re: Maven2 and Functional/Integration Tests In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_53227_22178059.1149573220325" References: <9e3862d80606052238h1c727aavafe179f14712fdd3@mail.gmail.com> X-Google-Sender-Auth: 0e618bd5c04606ed X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_53227_22178059.1149573220325 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/5/06, Wendy Smoak wrote: > > On 6/5/06, Brett Porter wrote: > > > It *should* still be possible to achieve what you want currently (I > > thought Vincent's chapter discussed that, but I don't might be > > mistaken). It may take some effort, though, and I'm not sure of any > > existing examples. The 'integration-test' phase was meant to be a > > general hook to facilitate this where possible. > > The problem I keep running into is that there is only one > /, and there is no > // in the model. If that > existed, it seems like you could get another execution of Surefire > using a second source directory. That's the key problem, and that's why the "duplicate" closing is going to neglect what I'm interested in. Maven2 needs to support integration testing as a first class notion in the architecture of what you envision a "project" to be. It's not just webapps .. you've got the same sort of issue with EJBs, or web services, or anything that gets deployed in a container. Unit tests just don't give you the confidence you need that the application will actually work. I've seen too many cases where all the unit tests on a webapp all pass with flying colors, but it throws an HTTP 500 on the welcome page because of a stupid coding error in the JSP page that wasnt' tested with the unit tests. What's needed is a complete additional test environment, with its own lifecycle, and its own classpath (i.e. dependencies tagged to this scope so you only load things like HttpUnit or HtmlUnit here). If integration tests exist, they should be part of the default "mvn install" processing, just like unit tests are, unless it is explicitly disabled. Don't pretend that there is only one kind of "test"!!! Otherwise, you guys are not being serious about trying to encouraging best practices in build environments :-(. Craig PS: (I'm going to paste the above comments into the bug report as well, so Maven folks who aren't subscribed here will see them.) You're hinting that it's possible, though... what am I missing? > > -- > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > ------=_Part_53227_22178059.1149573220325--