Re: [Htmlparser-developer] HttpUnit etc. was (Re: Table Scanner )

[Sam J. <ga...@yh...>]

Hi Somik

Somik Raha wrote:

>Hi Sam,
>  This is interesting - bcos I was doing much the same
>thing last evening. I've added a lot of searching
>methods into HTMLFormTag - as I was using this to do
>test-first development of an XSLT stylesheet. 
>  I was happy with the results - I was actually able
>to develop the stylesheet test-first.
>
Sounds cool.

>>I have started creating a TestCodeGenerator using
>>HtmlParser.  I am 
>>using an HTMLFormScanner to strip out all the form
>>details, and from 
>>this I hope to generate testing and handling java
>>classes ....
>>    
>>
>
>I will probably add some more utility methods into
>HTMLParserTestCase that will make life easier - but
>even in its current form, you might find it useful.
>
I think it will be.  At first I was thinking I wanted lots of additional 
methods, but actually I can predicate behaviour based on the TYPE of the 
input tags.  I'm getting output like this:


   [java] DEBUG [main] (TestCodeGenerator.java:296) - pTagName: FORM
   [java] DEBUG [main] (TestCodeGenerator.java:302) - attr: ACTION, 
value: $FORM_ACTION
   [java] DEBUG [main] (TestCodeGenerator.java:302) - attr: NAME, value: 
$EDIT_FORM
   [java] DEBUG [main] (TestCodeGenerator.java:302) - attr: METHOD, 
value: POST
   [java] DEBUG [main] (TestCodeGenerator.java:306) - x_inputs.size(): 7
   [java] DEBUG [main] (TestCodeGenerator.java:321) - pTagName: INPUT
   [java] DEBUG [main] (TestCodeGenerator.java:327) - attr: VALUE, 
value: add_bookmark
   [java] DEBUG [main] (TestCodeGenerator.java:327) - attr: NAME, value: 
$ACTION
   [java] DEBUG [main] (TestCodeGenerator.java:327) - attr: TYPE, value: 
hidden

and I think I can generate the necessary test and code shells from this.

>I've documented it here :
>http://htmlparser.sourceforge.net/design/tests.html
>
Interesting.  I'm becoming more and more commited to a test-first 
philosophy myself, i.e.

1.  write test
2. run it and watch it fail to confirm test will fail when 
implementation is not present
3. write the implementation
4. try and get implementation to pass test
5. repeat as appropriate

Although actually my post was more about automatic test creation rather 
than testing itself.  I recently found this:

http://www.junitdoclet.org/

which automatically creates test shells out of code.  And I found myself 
wanting the equivalent thing for httpUnit.  Either way round I think if 
people are going to do testing they need support to make it easier to 
create the tests.  And if they are working on the tests first they need 
support creating the implementation.

It seems that really we want something like:

1.  Specify use case, and data-in/data-out
2.  Automatically generate test code and shell implementation code
3.  Run test code to fail
4.  fill in implementaton details ...etc

Anyways.....

CHEERS> SAM

p.s. I'm impressed by the frequency with which you are releasing 
htmlParser, and your process of having multiple candidates etc.  I 
struggle to release often as the release process itself still seems a 
little cumbersome (sourceforge has got better) ....  have you any tips 
for streamlining it ....?  I guess what I really need is an ant methods like

ant release-bug-fix version
ant create-new-version-release
ant create-new-candiate-release

which handle all the necessary communication with sourceforge, 
uploading, packaging and handling of release numbers ....