Nicola Ken Barozzi wrote:...
Then add a test run target to the ant buildfine and make sure Gump runs it daily.
That's the thing. Write a test target...
What shape would a CLI test target take?
IMHO the first easy thing to do is to rely on Forrest, that uses Cocoon in a sufficiently complex way.
What is needed is a test site that is complex enough, and have Forrest run on it. If the build fails, it may mean that it's Forrest's fault or Cocoon's, but the important thing is knowing that there is an error.
Then, if the Forrest build succedes, the ant build can do other checks like the size of the files (>0), check that the files are actually there and not more and not less than defined, etc.
This is the functional test part, which is only part of the picture, and is to be done in Forrest. BTW, this makes it possible for us to gather statistics about Cocoon speed.
Then we have the unit test part, that is about testing the functionality of the CLI "unit", mainly of it's methods.
What I am doing now in my projects is to not try to devise clever tests from the start. Most tests that people write are of no use, or at least cost more to write than to fix the eventual bug later. IMHO writing tests is like writing code, and as I now try to KISS code, I want to KISS tests.
So actually I go the other way round current practice: I write only the tests that I know I need, not more.
Since you don't know what tests to write, simply to set up a functional test run, a simple CLI testcase, and check that they run on Gump. Then, each time a problem occurs or each time you see that you are defining a spec or contract that is not enforced in code, or that has to remain enforced, write this down in the testcase that is already there.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------