incubator-isis-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Haywood <dkhayw...@gmail.com>
Subject Re: "TCK" domain app (ISIS-108)
Date Wed, 20 Jul 2011 09:12:29 GMT
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.
>>
>
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message