Could you say a bit more about why it needs to be a runtime module not just somewhere like maven-web-junit, and what the issue is in point 3? (as you can guess my preference is for this to not be in the core runtime :))
...ant On Feb 4, 2008 9:57 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > 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://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] > >> > > >> > > >> > > > >
