Mail Archive Home | zeus List | January 2001 Index
| <-- Date Index --> | <-- Thread Index --> |
> -----Original Message-----
> From: owner-Zeus@xxxxxxxxxxx [mailto:owner-Zeus@xxxxxxxxxxx]On Behalf Of
> Spencer A Marks
> Sent: Tuesday, January 16, 2001 11:50 AM
> To: Zeus@xxxxxxxxxxx
> Subject: Re: Zeus: Plan of Attack and Timeline
>
>
> Hi,
>
> I might be albe to lead a hand in these areas:
>
> > 2. Code I/O Classes
> > * StreamSource
> > * StreamResult
> >
> > 3. Code Binding Interfaces/Classes
> > * Container
> > * Property
> > * AtomicProperty
> > * ContainerProperty
>
> Can you supply more detailed requirements so I can better judge?
This is building up the Java classes that represent Java objects. In other
words, any Java object that might be generated from a set of constraints can
be broken down into those categories:
An Object is always, at least, a Property.
A Container might have Properties. Therefore, objects with properties within
them (custom objects) are always Containers.
AtomicProperty is essentially a Java primitive, or primitive wrapper
(int/Integer, float/Float, etc.)
ContainerProperty is the meeting between the two.
So for this:
<complexType name="zeusTest">
<element name="foo" type="integer" maxOccurs="unbounded" />
<attribute name="bar" type="string" />
</complexType>
would need these bindings:
ContainerProperty (zeusTest)
ContainerProperty (foo)
AtomicProperty (each member of the foo list)
AtomicProperty (bar)
See, that is an arbitrary set of bindings that are independent of the
constraints, whether they be in schemas, dtds, etc. Then those are converted
to actual Java classes. That's sort of esoteric, but I think it will make
more sense once some of the interfaces are defined.
>
> >
> > 6. Test/Tune/Refine
>
> I am a big advocate of writing tests as (or even before) I write the
> actual class. I've had good success using JUnit (http://www.junit.org)
> as a testing framework. The strategy I follow is to write a test
> class for every
> concrete class. The test class tests every public method of the
> concrete class. This does not provide 100% coverage, but in my
> experience as been more than adequate. I have a make target that runs
> all the tests, which have to pass, before I check in any code.
>
> I appreciate the compressed schedule, however, I don't think writing
> tests along with classes takes much, if any, longer. I know there are
> differing opinions here, but I think the time costs of writing the
> tests up front are offset by time that would otherwise be spent in a
> protected debugging cycle. This argument excludes the longer term
> benefits of
> having tests upfront because they might not be of immediately advantage
> during a rush to get things done.
> (However, longer term advantages include the ability to easily refactor
> etc.) Anyway, I'll get the off the XP soapbox now. However, I'd be
> happy if this project's guidelines included a quasi requirement of a
> test class for every application class. How do people feel about
> agreeing to something like this?
I'll save you some campaign time. Tests are required, and I'm for one test
per one concrete class, and I'm for using JUnit. So there you go! Once I
have the interfaces, and we start coding classes (tomorrow, if things go
well), then I'm all for you starting on a test harness. In fact, I think
it's a must. So I'm for it!
Brett
>
>
>
> Spencer
>
>
> ------------------------------------------------------------------
> -----------
> To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
> with the text "unsubscribe zeus" in the body of the email.
> If you have other questions regarding this mailing list, send email to
> the list admin at owner-zeus@xxxxxxxxxxxx
>
-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe zeus" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-zeus@xxxxxxxxxxxx
| <-- Date Index --> | <-- Thread Index --> |
Powered by MHonArc.
Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.