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://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]

Reply via email to