Re: [Wheat-developer] comments on template attributes syntax

[Mark L. <ma...@gl...>]

Donovan:
> All use some sort of DOM structure to locate subsections of a page, 
> and all forced you to tag nodes for test with unique ids.
Kragen:
> My experience ... was that the "invisible" details of web
> pages changed a lot more than the "visible" parts.  Divs would become
> paragraphs; single pages would split into frames; links would become
> form submit buttons;

So, these seem at odds with each other: We test by comparing against 
the XHTML structure, but that structure is the thing that keeps 
changing.  For the person coding the model objects, and how those 
objects render parts of themselves, this is awful:  Every time the 
designer does one of those "invisible" detail changes, the tests for 
the model object fail, even though nothing is really wrong:  The test 
just tests the wrong level.

Now, I still believe that tests at the XHTML level are important - but 
those are more tests of the templates themselves than how the model 
objects render.

Donovan:
> The API I have settled on as lowest common denominator required 
> functionality is:
> assert(nodeId, nodeContents)
> follow(nodeId) -- follows a link
> post(formId, {fieldName: fieldValue, fieldName2: fieldValue2}) -- 
> posts a form

I noticed this about your in-browser tests.  These very much have the 
feel of acceptance tests, not unit tests.  Mostly because rather than 
explore the cases of how individual objects render, it follows a 
narrative of a user experience.

Indeed, when I looked at the examples for things like XMLUnit, 
HTMLUnit, JWebTest and Canoo Webtest, all of them have the same taste:  
In fact, often the examples only superficially tested that the content 
of the page contained what was expected (testing only the title or a 
string or two.)

Now, I realize there is a fuzzy line between acceptance test and unit 
test in this case, but the differences in terms of who writes the tests 
and what sort of things they cover are still there.

So, I think I still want to do the "template trace" style of tests so 
that the model object author can write server side unit tests that 
prove that:
	a) the object implements all the tt- names the way they are expected 
(replacing with strings, skipping, keeping, or expanding in a loop 
properly).
	b) the template and the object agree on the set of tt- names (template 
doesn't ask for things the object doesn't expand, and the template does 
ask for everything the object expects it to)  There is no need for this 
kind of test to involve an end-user browser, since the browser doesn't 
influence this level of rendering.

In addition, we also want to ensure the application as a whole works, 
and this kind of test is written by the template designer and customer 
to ensure that the links work as expected, and that the pages represent 
the correct things.  This seems to be the kind of test that I saw in 
nevow, and I agree that it make lots of sense to have this sort of 
thing actually driven through/by a live browser.  I love that it gives 
you a great way to test cross-browser compatibility of the application.

I wonder if perhaps this splitting into two layers of tests is what's 
missing in HTTP/HTML application frameworks.  As I said, everything I 
found had people throwing their hands up.  Perhaps, by introducing a 
layer here, we can have what we need in each piece, rather than trying 
to come up with one piece that does it all.

Looking at Selenium, why did nevow need its own version?  Why couldn't 
Wheat just use Selenium?

	- Mark