I'm afraid I think it's way too early to try to categorize where
tests should go. Based on my experience so far I think we need to
work on simplifying how to set up a small app and have some simple
tests for it first. Once we have enough of these to confuse
ourselves about organization, and it's dead simple to write a new
one, we can worry about categorizing them.
For instance it might be useful to have a maven archetype to set up
everything except the app to test and the actual test cases.
thanks
david jencks
On Dec 7, 2006, at 8:31 PM, Prasad Kashyap wrote:
Since there were some questions today on where to drop new tests, I'll
take a stab at creating a convention. Feel free to offer your
suggestions so that we can modify it as we go along.
We began by having 2 testsuites just as an example.
geronimo/testsuite/
console-testsuite
deployment-testsuite
But almost everything can fall under the category of the
deployment-testsuite since most tests do need some deployable
artifact. So I think we should use the deployment-testsuite purely for
testing the deploy tool. Especially, it should be used to test
features like hot-deploy, redeploy and undeploy which have had JIRAs
before.
We should categorize the tests so that they reflect the broad
functional areas of the server.
* web-testsuite (servlets, jsp, jstl)
* enterprise-testsuite (ejb, jpa, jms, jacc, jta, javamail, jaf etc)
* mgmt-testsuite (jee management, deployment)
* webservices-testsuite (wsee, jaxb, stax, saaj, ws-metadata etc)
* performance-testsuite (server startup time, server footprint etc)
* security-testsuite
* console-testsuite
* regression (compatibility)
If nobody has any objection to this top categorization, I shall go
ahead and create these testsuites over the weekend. Meanwhile you may
drop your tests in the existing testsuites for now. I shall move them
appropriately.
Lastly, how do we deal with super apps like daytrader that can span
across multiple testsuites ?
Cheers
Prasad
