Hi all,
Just a heads-up.
For the new JSON viewer (and for other viewers in the future) I want to
have proper automated end-to-end tests (rather than simple unit tests).
So I've hit on the idea of there being a standard "TCK" domain
application (TCK = technology compatibility kit, ie for testing that new
components such as viewers or object stores are compatible with/provided
the same capabilities as existing viewers/object stores).
Anyway... what this post is here is how to I intend to structure this
TCK domain app.
What I've done is use the archetype to generate a domain app; this
generates multiple modules. What I propose is that the "core" of the
app (dom, fixtures and objectstore-dflt repository impls) go into an
org.apache.isis.tck package (under trunk/framework/tck), but then the
modules for the various viewers (dnd, html, wicket, scimpi, json, xhtml,
bdd, junit) are moved out alongside the implementations to be maintained
there). Then - on a case by case/component by component basis - we can
write end-to-end tests for this component and with respect to the
standard TCK app.
That is, in trunk/framework there will be:
tck/
dom/
fixture/
objectstore-dflt/
viewers/
dnd
dnd-tck # for end-to-end tests of the DnD viewer against the TCK
app (original code corresponds to the 'quickrun' module generated by the
archetype)
html
html-tck # for end-to-end tests of the HTML viewer against the TCK
app (original code corresponds to the 'viewer-html' generated by the
archetype)
json
json/tck # for end-to-end tests of the JSON viewer against the TCK
app (original code corresponds to the 'viewer-json' generated by the
archetype)
scimpi
scimpi/tck # etc
bdd/concordion
bdd/concordion-tck # etc
wicket/viewer
wicket/viewer-tck # etc
junit
junit-tck # etc
xhtml
xhtml/tck # etc
You get the idea.
Since this is new code, I don't think it'll impact anyone; but I wanted
to describe here what these new modules are all about.
Reply here if you have any views/modifications/improvements to this scheme.
Cheers
Dan
