geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Anderson" <...@netspace.net.au>
Subject RE: [Testing] Testing
Date Tue, 12 Aug 2003 10:20:01 GMT
The JMS CTS (http://jmscts.sf.net) does something similar,
except that rather than using section numbers, it associates
an identifier with each requirement.

A requirement can then be associated with multiple sections of
the JMS spec, useful when a requirement is covered in multiple
places.

It also saves on verbosity, which helps if more than one test
case tests a requirement.

All requirements are maintained in a .xml file e.g.:

   ...
  <reference referenceId="section.6.11.1">
    <section name="6.11.1" title="Durable Topic Subscriber" />
  </reference>
   ...

  <requirement requirementId="subscriber.durable.unique">
    <description>
      Only one session at a time can have a TopicSubscriber for a
      particular durable subscription.
    </description>
    <referenceId>section.6.11.1</referenceId>
    <referenceId>section.4.3.2</referenceId>
  </requirement>

(from
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/jmscts/jmscts/src/java/org/ex
olab/jmscts/requirements/requirements.xml)

And referenced in code using the @jmscts.requirement tag e.g:

    /**
     * Verifies that creating a duplicate durable subscriber in the same
     * session throws JMSException
     *
     * @jmscts.requirement subscriber.durable.unique
     * @throws Exception for any error
     */
    public void testDuplicateSubscriberPerSession() throws Exception {

-Tim



> -----Original Message-----
> From: Alex Blewitt [mailto:Alex.Blewitt@ioshq.com]
> Sent: Tuesday, 12 August 2003 7:25 PM
> To: geronimo-dev@incubator.apache.org
> Subject: Re: [Testing] Testing
>
>
> > I agree that it's duplicate info. One reason is to make the tests as
> > self-contained as possible. This makes report generation easier because
> > there is no dependency on an external, separately maintained resource.
> > Maybe it is too much data and isn't necessary? Maybe the following is
> > more reasonable:
> >
> > @spec
> >     name="J2EE"
> >     version="1.4"
> >     chapter-name="Transaction Management"
> >     section-name="Transactional JDBC Technology Support"
> >     section-number="4.2.7"
> >     page-number="64"
>
> I think you'll end up with a situation where a spec-test developer will
> just put in the section-number, since that's essentially what
> highlights it. Also, if the section is prefixed with a document name
> (J2EE_1.4-4.2.7) then you can pretty much get rid of everything else.
>
> I agree that having everything self-contained is good, but I can't see
> developers caring about typing in chapter-name and section-name each
> time they need a test. It should be relatively easy to put the sections
> in a properties file listing each of them and just do a lookup (using
> J2EE_1.4-4.2.7 as a key in a properties file)
>
>   :
> J2EE_1.4-4.2.7=J2EE 1.4: Transaction Management (Transactional JDBC
> Technology Support)
>   :
> J2EE_1.4-6.17=J2EE 1.4: Java Management Extensions
>   :
>
> (see attached file)
>
>



Mime
View raw message