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. >
