On Aug 8, 5:59 pm, "Leslie P. Polzer" <[email protected]>
wrote:
> Maciej Katafiasz wrote:
> > how do y'all people test unit your weblocks code? I'm referring to
> > things like testing the output of widgets that use RENDER-LINK
> > internally etc. Some ogling of the weblocks-test sources suggest it's
> > avoided when possible, but that doesn't explain how things such as
> > gridedit are tested, and I'm not able immediately to find out from the
> > code.
>
> The magic is in test-code/weblocks-suite.lisp. We frob in our custom
> version of GEN-ID that just returns a static string.
Ah, I see.
> > What I'm getting at is that DEFTEST-HTML simply compares results as
> > string, but that's hopelessly non-robust in HTML.
>
> Yes, but there is research in that direction. Take a look here:
>
> http://weblocks.lighthouseapp.com/projects/18897/tickets/16-fuzz-up-h...
>
> > We're currently contemplating one of the two possible
> > approaches, either Selenium or writing a simple programmatic browser
> > on top of Drakma and closure-html, but if a good way exists inside
> > weblocks-test already, I'd prefer to use that.
>
> I would suggest you take a look at #16 and the code that Stephen has
> written so far and try to complete it. This will make HTML testing much
> easier for everyone.
Right. I was thinking of creating an API to express symbolically
things about the HTML we expect, along the lines of Python's/Perl's
mechanize, but a unification is also an option. I'll have a look.
Cheers,
Maciej
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---
