Hi Steve, > -----Original Message----- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: mercredi 4 janvier 2006 14:37 > To: Maven Developers List > Subject: Re: [discussion] Integration testing location
[snip] > > For example cargo could define a cargo:test goal which would start the > > container, run the tests and stop the containers. But this doesn't lead > to > > all variations like: > > - the user simply wants to redeploy the new artifacts in the container > but > > not start the container again > > - the user want to have his/her tests written using tetstng and not > junit > > (or any other test framework) > > > Sounds more like functional testing to me...anything that needs a > deployed system is a v. more complex situation. Ah, I guess it depends on the definition of it vs functional tests. For me it's only a question of context. For example, I have a project with wars, ejbs, ears. I want to be able to do two things: - Inside the ejb project, I want to be able to run unit tests but also integration tests. I don't want to run many its. Just one or two that proves that my ejb can be deployed and works. For that I want to use cargo without having to define any configuration. Cargo is perfect for this use case as it provides a default config for me. Still I call this IT and not functional testing. - I want to have a system/ project where I'll run functional tests (aka system tests in this case) where I'll have all the different components deployed (the ear and all). For this functional test, I want to run with the real configuration I'll use for deployment. > I am working with a PhD student at CERN on distributed testing, and > there is a project gridunit that does some good stuff already, running > junit tests across a farm of nodes, collecting and presenting the > results. Wow, that sounds really cool! Especially as there's a grid already in place (http://www.lsd.ufcg.edu.br/~alex/doku.php?id=gridunit). Is there an integration with a CI already in place? (I'd love to try it out for building Cargo - It has lots of tests and this would help a lot). Some time back I had blogged about distributed build (http://tinyurl.com/42zc7). This is still something I'd love to do. I agree that distributed test is a different topic than distributed build but combining the two would be even greater... ;-) > Clearly presenting the results gets more complex once you have > tested on 20 boxes; you want to know what failed everywhere, what failed > somewhere, and if there is any commonality for the partial failures. > > The perspective we are taking is that a test run is just another thing > to deploy; you have a test listener to collect results and logs from > across the machines, then test runners on different machines running > different tests. The listener collects the results, post-processes them > and then you can act on the outcome (report failures, host the reports, > etc). > > In this view, functional testing of a deployment is just another > deployment. Its different from a production deployment, but not very; > just a different deployment descriptor to process. Cool -Vincent --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
