incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer" <ke...@kmz.co.za>
Subject Re: "TCK" domain app (ISIS-108)
Date Wed, 20 Jul 2011 08:31:53 GMT
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.
>



Mime
View raw message