[Webtest] [dev] discussions

Dierk Koenig webtest@lists.canoo.com
Wed, 22 Sep 2004 17:44:17 +0200


> it's a general consideration. One of the last cases was the 
> introduction of Jetty.

I discussed this with Denis face-to-face. He is very proficient in 
creating self-contained builds (and not only there).

> Click-O-Mat and ResultViewer don't matter as they are independant tools.
> For Groovy, it brings a question: what do you want to put into 
> extensions? 

Actually I put everything in the extension package that is not
complete. To be complete, a step needs to have:
- code 
- unit tests
- selftests
- a reasonable coverage
- documentation

The GroovyStep currently lacks the documentation in the syntax.xml and
unit tests for bad combinations of parameters.

> Till now I thought it was a kind of sandbox 
> for non fully selftested steps. As a consequence, I didn't feel 
> concerned to migrate these steps to htmlunit in a first 
> time. Now you have Groovy tests in the extension package and they 
> have selftests too.

OK. I understand that the changes to webtest codebase interfere with
your migration effort.
For me it would be ok to ignore the extension steps while migrating.
I'm happy to do the migration work of the extension steps 
afterwards. You can disable any "extension selftests" on your
migration "branch".

> What I'm missing is some discussion on a "road map" or when 
> something has been done, some explaination on the reason. 

Feel free to ask about any puzzles.

As far as changes are observable to the user, I try my very best to
explain it on the http://webtest-community.canoo.com blog and on this list.
As far as developers are concerned I try to give good comments in 
the CVS (but admittedly not always) that can be easily explored 
through http://webtest.canoo.com/fisheye/ .

A "road map" doesn't really fit with webtest as the development is
very opportunity driven. The great possiblity of using Groovy was never
foreseen. Same with the currently integrated Applet testing support.
But we could certainly introduce a file /todo.txt to keep track of
already identified issues.
Would this address your needs?

> For example the selftests are now as small files in the selftests 
> dir what is really a good thing to simplify/clean up 
> the source structure but for instance why are the old versions 
> always in place?

Obsolete files should be deleted. 
Please do so if you find any.
There is no reason to keep them.


cheers
Mittie