Hi Kevin,
what I do is to import the entire framework/trunk tree into Eclipse, and
this tree *would* include the various TCK modules.
As things are right now in the SVN repo, the TCK modules are all in a
single directory. The reason I want to break it up is that -
realistically - not every component is likely to use the TCK for a
while. Having the TCK together might imply to the casual browser that
there is TCK coverage when there isn't any.
Let me complete the commit to what I was proposing, and we can see how
it feels.
Cheers
Dan
PS: or, as an alternative, maybe we should simply delete those TCK
modules for viewers that don't have any automated tests.
On 20/07/2011 09:31, Kevin Meyer wrote:
Hi Dan,
I sense the usual problem of a linear file system interfering with
a desire to store something that conceptually belongs in two places!
;)
I think this could work, but perhaps I would prefer if the TCK
application be internally complete, i.e. in Eclipse I can import 1
project that includes *all* TCK modules (I'm thinking about project
maintenance refactoring). Leaving links (either symbolic or via
svn:externals) doesn't quite solve this issue...
If we communicate well enough (and include a reference to the TCK master
project in the module , e.g. objectstore, documentation) we can
manually/intellectually be aware that each module has a tie-in to the
TCK application.
My 2c.
But otherwise, yes, this is a good idea.
Regards,
Kevin
On Wed, July 20, 2011 09:41, Dan Haywood wrote:
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.
