Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [hyades-dev] Re: integration vs interfacing

From the size of the soap box obviously this white-box vs. black-box 
thing exercises a lot of people, but personally I've always seen value 
in both approaches, and I think amongst Hyades launch goals was to be 
methodology-neutral.

I think there's one important strand that hasn't been aired. When we at 
Hyades say we support JUnit as a sample tool this means that we ship the 
jars, ensure it is all buildable under CPL or in due course EPL, 
document its use and support it for our consumers.  This means that 
companies building commercial offering can extend the framework and/or 
the sample tools under a common licence, and raise defects against us 
and we are committed to fixing them.  Subject to fixing the CPL/EPL 
disconnect I think we are reasonably safe for Junit but if we move to a 
broader support of these derivatives we may end up with some support 
headaches.

Mike

-----Original Message-----
From: tlroche [mailto:tlroche@xxxxxxxxxx]
Sent: 19 September 2004 20:21
To: hyades-dev
Subject: [hyades-dev] Re: integration vs interfacing


Tom Roche 16 September 2004 19:09
>>> I advise instead creating an extensible platform, and
>>> demonstrating the ease of plugging into it, because you will never
>>> have as much resource as the entire JUnit community. (Not to
>>> mention xUnit

<snip>

>>> why not start by publishing (or pointing to) the "architectural
>>> guidelines [used by] the existing sample tools that Kent's team
>>> and others have been building," so we can get a better idea of
>>> what's involved in integration? Or, alternatively, if those
>>> guidelines are better interpreted as platform interfaces?

Michael.Norman Fri, 17 Sep 2004 19:16:13 +0100
>> You may or may not have noticed I was being deliberately
>> provocative.

I try not to assume anything when dealing with management--I always
get it wrong :-)

>> Our charter and the Eclipse project allow us to build both tools
>> and frameworks. Basically we can go 2 ways here, build a sample
>> tool that maps scripts from the Junit derivatives into Hyades
>> Behaviours, or integrate them all as external behaviours. There's
>> probably some intermediate position, and there may not be a
>> one-size-fits-all soution.

more below

"Saliba, James" Fri, 17 Sep 2004 17:13:20 -0400
> From my point of view the larger portion our audience is not doing
> "green fields" development; people are extending and build on
> existing products/projects. Therefore we must make Eclipse/TPTP
> attractive enough for people to want to switch.

Precisely!

> I believe this would include items from three general areas:

> 1) Test/Project management (really another topic)

Yes: this is definitely a layer above JUnit (but therefore where
Hyades can add value).

>      How many tests do we still need to write?

i.e. coverage?

>      How many of the tests are passing/ fail?
>      How many of the tests past before or failing now?
>      How many defects are there?...

> Many teams don't have this level of management and sorely need it.
> By providing this management support and reporting capabilities
> (canned or not) people have reason to come over.

Or their mgmt has reason to march them over :-)

> 2) Existing test cases   (interfacing)

> The testing teams already have a large investment in test cases. We
> do not want them to rewrite them. These test cases can be in the
> form of scripts (perl, python, etc.), open source tools (Grinder,
> HttpUnit etc.), and/or commercial tools (winrunner etc.)

> Interfacing tools allows teams to keep their current investment.

> 3) The ease of writing new test cases with Eclipse/TPTP 

I would add one more

4) The ease of maintaining test cases developed with Eclipse/TPTP

FWIW 3 and 4 are my primary concerns: specifically, reducing the total
lifecycle cost of testing for *developers*, in order that they and
their management will see the (admittedly overhead) cost as
acceptable, and begin to consistently/continually do automated
testing, rather than pushing it off to "dedicated" or "3rd party"
acceptance-type/black-box testers. But that's a topic for another
thread ... suffice to say that, IMHO, while black-box tools have made
progress in lowering the cost of _creating_ tests, tests thus
created/run will never be as maintainable (or even, in many cases, as
easy to develop) as those developed using xUnit-based tools that

* allow developers to create tests as (or even before) they develop
  their sources

* leverage developers' {access to, knowledge of} their sources

* are more easily integrated into development tools and processes

<off soapbox/>

> and the promise of further tool plug-in's from open and commercial
> sources (integration?)

I would call that interfacing (reserving "integration" for tighter
coupling, like the "Norman Conquest" previously proposed :-) YMMV.

>      U2TP to auto generate test cases etc.

> Also, there are many testing tools that are junit extensions.  It 
seems
> that every time I talk to someone I find out about a new one.

Indeed! E.g. see

http://www.tagunit.org/tagunit/index.jsp
http://today.java.net/pub/a/today/2004/07/05/TagUnitIntro.html
http://today.java.net/pub/a/today/2004/08/30/TagUnitIntro.html

about which I first heard Friday (17 Sep).

> Should our Junit derivate support select a few tools and integrate
> them or do we provide a way for people to integrate any tool they
> want by giving a few examples?

Why not both? E.g.

0 Create/spec some base interface corresponding to "external behavior"
  as described. This would allow Hyades to interact with JUnit
  extensions that know nothing about Hyades. (From list traffic, it
  sounds like youse already have enough experience with this to
  specify this layer--correct?) This would be the "way for people to
  integrate any [JUnit extension] they want" (within reason :-)

1 Select a few JUnit extensions and them as, umm, "test cases" for the
  development of higher-level interfaces, to wit:

2 Create/spec successively higher interfaces (or "layers of
  integration," YMMV) allowing a JUnit extension to more greatly
  {leverage, take part in} Hyades, e.g. emit CBEs, contribute UIs.
  These would hopefully share the "architectural guidelines [used by]
  the existing sample tools that Kent's team and others have been
  building."

3 Use the stack to create

Michael.Norman Thu, 16 Sep 2004 14:04:49 +0100
>>>> a new Hyades Sample tool, sharing code with the existing sample
>>>> tools that Kent's team and others have been building, and
>>>> following all the same architectural guidelines,

demonstrating the various interfaces (and Hyades' value-add).

_______________________________________________
hyades-dev mailing list
hyades-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/hyades-dev



Back to the top