|
From: Darren D. <dda...@kg...> - 2003-12-01 11:13:01
|
I've finally got something concrete in place for the application testing
stuff, but I need some thoughts from people before continuing much further.
The code written so far is fairly tightly tied to both the sample application
and the server that it will be deployed upon. This is inevitable, but it's
also written in such a way that various tests can be called from a 'master'
script in a standard and parameterised fashion.
As a result, there are a number of dependencies that the autobuild code will
need to rely upon; namely
1 - each sample app has a build.xml in the root folder (eg
samples/petclinic/build.xml). Currently this is the case, ideally we need to
adopt it as an internal standard.
2 - each sample app's build.xml contains a 'warfile' target that leaves the
deployment unit in a directory called 'dist' off the sample app root.
Currently this is the case, but probably won't be if non-web sample apps are
developed. Perhaps a more generic target name of 'dist' would help if this
occurs.
3 - clearly the application tests (HttpUnit) are tied closely to the view
structure of each sample app in the same way as JUntit tests are tied to the
structure of classes they test. Once tests are commited, changes to the
sample apps will have to take this into account and involve changes to the app
test code too. An alternative would be to develop one or more sample apps
purely for the purpose of build & deployment testing so that sample apps are
free to be developed along a more user-educational line without concern for
auto-builds. The downside is that the purpose developed apps are likely to be
unrealistic and biased to passing tests which defeats much of the purpose of
doing it. Personally, I prefer the idea of using the existing samples.
In summary,
- any strong feelings plus or minus for changing 'warfile' target names to
'dist' or 'deploy-unit' or something in the sample apps?
- any preference for creating new (test-friendly) apps for this, or using the
possibly more real-world existing sample apps with the additional overhead of
maintaining test source if the sample apps themselves change?
Just for info, I'm snagging the following namespaces in the project for this:
${spring.root}/autobuilds (and sub-dirs)
${spring.root}/target/autobuilds (and sub-dirs)
org.springframework.apptests.* (package root)
org.springframework.autobuilds.* (package root)
.. just in case anyone else was thinking of using them :-)
Darren.
--
Darren Davison
Public Key: http://www.davison.uk.net/key.jsp
|