Re: Zeus: Plan of Attack and Timeline

[Spencer A Marks <smarks@xxxxxxxxxxxxxxxxx>]

I have limited time so I am trying to be careful not to sign up for
too much. However, I can easily  handle the JUnit testing framework. I
am investigating the I/O class stuff now. The binding stuff seems most
interesting (to me) but I am not sure I'll have enough to keep up with
your schedule for that. 

Spencer



"Brett McLaughlin" <brett@xxxxxxxxxxxxxxx> writes:

> > -----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
-----------------------------------------------------------------------------
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