>> req for output framework


o) should display the code inside the assert block with already
   substituted values, e.g.

   if assert { $some_no == 5 } fails, ith should say something like
   that:

   assertion { $some_string == "bla" } -> { "bli" == "bla" } failed.



o) should display the previuosly executed lines of code of the .test
   file, so that one quickly sees what has happened before.


o) allow for debugging msgs to quickly develop tests

- by inserting a "debug" command? Maybe distinguish between .test
  debug calls and calls from within tclwebtest (something like
  debug_internal if not possible otherwise?). Both can be explicitely
  turned on when running a test (off by default).

  Maybe we need a "verbose" command too, for output that is designated
  to be read in case of failure.


o) allow for redirection to a file - also if several tests are running
   simultaneously. should contain timestamps and allow for
   cumulatively running the tests again to keep a record of previous
   successes and failures.


o) output a final OK or FAILED as summary of all tests that have been
   run.











>> General
Must follow redirects. Optionally fail on a specific number of
circular redirects.


Must remember Cookies.


Optionally remember other Headers too, like Basic Authentication.

Optionally use https



Easy to script a single user - common case. Should also be possible to
simulate multiple users/sessions in one test script. E.g. user orders
some stuff, admin logs in and tests if the order has arrived correctly
in his workspace.


Must enable to put common actions (like logging in) in a seperate file

Deal with known bugs - it must be possible to temporarily suppress
certain failures, while still being able to easily locate the places
where tests have been disabled.


Save result into an easily movable format, so that it can be looked at
with browser locally. E.g. normalize all links and download the page
and all images, css and (maybe optionally) object files such as .jar
etc. files. 

Launch browser with the downloaded content.

Use it to crawl and download files (actually only for micromusic ;-).



Report to stdout, optionally into a file. Roll old files. Report date
information to make logfiles historically meaningful.

Optionally report timing data, like average request duration, peaks
etc.

Return 0 when successful, 1 upon failure.


Clear non-persistent Cookies to simulate closing and reopening the
browser.

Receive emails ??? Easy when there is some sort of webinterface
available for the mails.

Test uploads


>> Analysis of result

Doing a request always asserts a final HTTP code of 200, maybe with
option to assert a specific HTTP return code.


Maybe: enable sort of a NOT-regex condition

Get all links to search them in the script

As convenience method: get first link that matches a certain regex

Or: assert that there is only one and get link that matches one or
more (not-)regexes. Really necessary to be able to say: only one
match?

Search links with images.

Assert for certain regexes and not-regexes in the page body. Maybe
with option to parse out all html. Optionally just parse out all <!--
-->. Hmm.


Get first form, optionally with regex match (on what - action="", some
text, name="" ?) Must be easy to get the expected form. Most of the
times there will be only one form anyway, maybe just distorted by a
search thingy that's on every page.

Assert the existence of certain form fields and fill them with
specific values. 

Assert existence of a submit button when there are more fields than
just one text field automatically.




>> Stand-alone app vs. ACS package


As standalone it would be easier to test from different remote
computers.

Stand-Alone propably easier to do stress testing. Start 100
test processes from a shell script.

ACS package could integrate with the existing test-harness package.



>> User scenarios:

Text editor, browser and terminal open - typing a testscript quickly
in the editor and trying it out immediately.


Package test scripts with a web application, possibly to try out
the whole suite with one command.


Stress test an application by concurrently running many tests.




>> Misc

Maybe realize this: http://acs40.arsdigita.com/doc/install-guide/tests.html