Hi,

I don't have a strong preference. Let's try to get the basic function working well first. A few points to think about before we refactor it.

1) maven-web-junit is a maven plugin under tools. We need to add another runtime project under modules folder. 2) host-webapp adds the junit as a runtime dependency which is not great but not too bad. 3) Configuring two servlet filters conditionally is a bit complex :-). We can also disable the /junit unit with an init-parameter "junit.enabled" set to false.

Thanks,
Raymond

----- Original Message ----- From: "ant elder" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Monday, February 04, 2008 7:14 AM
Subject: Re: [PROPOSAL] Automate itests for WAR packaging


If this is just for itests then to keep runtime cleaner how about moving it
all out of the main runtime code into the maven-web-junit module? So move
WebTestRunner, XMLFormatter, add a new ITestTuscanyServletFilter that
extends the TuscanyServletFilter to add the /junit hook and revert
host-webapp, and the web.xml in the itest/services module can refer to the
new  ITestTuscanyServletFilter?

  ...ant

On Feb 4, 2008 2:53 PM, ant elder <[EMAIL PROTECTED]> wrote:

Fine sorry i'd misunderstood before, the bit about adjusting the
sample-calculator-webapp to use this had me thinking the intention was to
add this in to all the samples.

   ...ant


On Feb 4, 2008 5:09 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:

> Hi,
>
> There are two objectives here:
>
> 1) Reuse our itests in the webapp packaging scheme with little efforts
> to
> convert. Automate the itests in web containers and report the results > at
> the
> client side.
>
> 2) Automate the start/deploy/undeploy/stop of the web applications
> against
> various web containers (such as Tomcat, Jetty, Geronimo and WebSphere,
> WebLogic).
>
> Most of the changes I made is to support 1). I also put some
> declarations
> (including cargo and geronimo-maven-plugin) in the pom.xml to support
> 2).
>
> With this, we can reuse most of our itests to run under the web
> environment
> without little efforts to convert. The test cases stay as regular Junit
> test
> cases. The client side doesn't have to write HtmlUnit to deal with the
> HTTP
> conversation.
>
> Thanks,
> Raymond
>
> ----- Original Message -----
> From: "Luciano Resende" <[EMAIL PROTECTED]>
> To: <[email protected]>
> Sent: Sunday, February 03, 2008 4:04 PM
> Subject: Re: [PROPOSAL] Automate itests for WAR packaging
>
>
> > By going with this approach, we can reutilize a lot of existing tests
> > (our iTests for example), instead of having to create/migrate new
> > tests using htmlUnit. As for cargo, it does not support all the
> > hosting platforms we are supporting, right ?
> >
> > On Feb 3, 2008 2:42 AM, ant elder <[EMAIL PROTECTED]> wrote:
> >>
> >> On Feb 1, 2008 5:41 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> >>
> >> > Hi,
> >> >
> >> > (Sorry for the long text, I make it availabe on our WIKI too:
> >> >
> >> >
> 
http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Automation+of+itests+in+web+applications
> >> > ).
> >> >
> >> > In our WAR packaging scheme, we package SCA artifacts with Tuscany
> >> > runtime
> >> > jars in a WAR so that it can be deployed to a web container such > >> > as
> >> > Tomcat,
> >> > Jetty or Geronimo. In release 1.1, we already have 5-6 samples as
> web
> >> > applications.
> >> >
> >> > 1) Most of the validation of web applications is done manully
> before a
> >> > release. This is time-consuming and error prone.
> >> > 2) Our integration tests are not performed in the WAR packaging
> scheme.
> >> > Trying samples is a smoke test. If we can run the itests in a web
> >> > application, we'll get much more coverage.
> >> >
> >> > To address the above issues, I propose that we add the following
> >> > capabilities:
> >> >
> >> > 1) Provide an option to wrap itests into web applications with
> little
> >> > effort
> >> > to convert the test cases
> >> > 2) Automate the steps to start/stop a web container and deploy web
> >> > applications to the container
> >> > 3) Automate the testing of our JUnit-based test cases in the web
> >> > application
> >> >
> >> > I did some prototyping and here is what I have achieved so far:
> >> >
> >> > 1) Add some code to
> >> > "org.apache.tuscany.sca.host.webapp.TuscanyServletFilter"
> >> > (tuscany-host-webapp) to intercept the HTTP requests to a special
> path
> >> > "/junit". The control is then delegated to a new class
> WebTestRunner
> >> > that
> >> > knows how to find and run the JUNIT test cases and produce the
> results
> >> > of
> >> > the test (for example, number of runs, failures and errors, > >> > similar
> >> > with
> >> > what maven surefire plugin does). The report is sent back to the
> web
> >> > client.
> >> >
> >> > With this, we can run the plain JUNIT test cases in the web
> application
> >> > by
> >> > connecting to a URL like http://localhost:8080/<app-name>/junit.
> >> >
> >> > 2) Adjust the sample-calculator-webapp to validate the idea
> >> > * Add a test case calculator.CalculatorTestCase
> >> > * Configure the maven-war-plugin in the pom.xml to include the > >> > test
> >> > classes
> >> > as a jar into the WAR (WEB-INF/test-lib/)
> >> > * Change the junit dependency from test to runtime so it will be
> >> > packaged
> >> > into the WAR
> >> >
> >> > 3) Run the maven build as ususal, produce a WAR, deploy to Tomcat,
> >> > browse
> >> > to
> >> > http://localhost:8080/sample-calculator-webapp/junit, and see the
> test
> >> > results in the browser. To run a selected list of test cases,
> >> > http://localhost:8080/sample-calculator-webapp/junit?test1,test2.
> >> >
> >> > This seems to be non-invasive as we already configure the servlet
> >> > filter
> >> > for
> >> > web applications. The regular URLs to JSPs or web services stay > >> > the
> >> > same.
> >> > We
> >> > don't have to change the test case code too much.
> >> >
> >> > I also went a bit further:
> >> >
> >> > 1) Developed a maven plugin to trigger the web-based junit tests
> and
> >> > analyze
> >> > the results
> >> > 2) Configure the pom.xml with cargo plugin to start an embedded
> Jetty
> >> > server, deploy the WAR, trigger the web-based junit tests, and > >> > stop
> the
> >> > server.
> >> >
> >> > Now I have a complete automation. To avoid repeating the pom
> >> > configuration
> >> > for each itest, we can add a profile in the parent pom to support
> this
> >> > scheme.
> >> >
> >> > For Tuscany itests, we also have to figure out a way to avoid the
> >> > conflicting bootstrap in the J2SE and web.
> >> >
> >> > Your feedback is welcome.
> >> >
> >> > Thanks,
> >> > Raymond
> >> >
> >>
> >> +1 to automated testing of the samples, demos and tutorials.
> >>
> >> Sounds like you've already done a lot of work on this, but i don't
> >> understand why this really complicated custom framework is > >> necessary,
> >> what
> >> does it give that we need which the standard cargo and htmlunit
> testing
> >> wont
> >> provide?
> >>
> >>    ...ant
> >>
> >
> >
> >
> > --
> > Luciano Resende
> > Apache Tuscany Committer
> > http://people.apache.org/~lresende<http://people.apache.org/%7Elresende>
> > http://lresende.blogspot.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to