> -----Original Message----- > From: Vincent Massol [mailto:[EMAIL PROTECTED] > Sent: vendredi 6 janvier 2006 15:59 > To: 'Maven Developers List' > Subject: RE: [discussion] Integration testing location > > 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.
Actually after some more thinking, I'm not 100% convinced about what I wrote... ;-) It could work but there are issues with it. For example the EJB will eventually call a database so there'll be a need to setup a DB too. Yeah sure Cargo could do that in the future too but then, say some EJB need to talk to a JMS server, etc. So I do agree that for lots of cases this requires a real functional tests. There can be some valid use cases for IT though even though I guess they'll be pretty few compared to the need for unit and functional tests. One useful EJB it test though would be to validate that the ejb-jar.xml and the proprietary container-specific deployment descriptors are valid. I guess this could be achieved by some container tool. Not sure they exist across the board though. So one way to do that would be to start the container and deploy the ejb to it using Cargo. That may fail if the container tries to set up the datasources and the DB is not ready... So no clear solution here... It depends I guess is the best answer... WDYT? -Vincent > - 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]
