RE: Early XSLT's

> [mb] I would prefer not to see additional efforts, rather for 
> those who are
> interested in DOM testing to contribute to the
> W3C DOM WG effort.  I'm sure we can work out a way that a generic
> transformation can be made available as a
> starting point for a particular language -- I would think that placing
> additional licenses and personal copyrights on
> the transformations will inhibit the overall effort, not 
> contribute to it.

I've been working under an assumption of good faith and have been making stuff available with no explicit copyright or terms of use.  However, I'm starting to get a little uncomfortable with my
personal exposure by doing this.  By asserting a copyright and GPL, I at least cover myself by providing a standard liability disclaimer.  I'm still free to donate the code to the W3C, when and if
desired, to be released under an appropriate license.

Whether code generation templates are part of the test suite or part of a specific harness implementation is questionable.

> > I should be able to make the code JUnit independent, 
> however test classes
> will require that the base class, DOMTestCase, provide 
> JUnit-like functions
> such as assertTrue, assertFalse, etc in addition
> > to implementing utility functions like load, 
> implementation, wait, etc.
> >
> 
> [mb] I would expect that these functions would be implemented 
> as part of the
> transformation, given that they will have to be
> done for each language.  There can be a set of helper 
> functions that get
> created for each language, and are then called -- which
> makes for good coding practice, but requires that these functions be
> available along with the tests, or the logic can be inlined
> in the transformation -- which makes for stand-alone tests, 
> and fits in with
> contributions coming from many places.

I wouldn't expect them as part of at least this transform since it is concerned with building individal java source files from individual test files.  The implementation of assertTrue, assertFalse,
load, etc is not specific to any one test and is best implemented in a hand coded common ancestor class.  The implementation of these functions depends on the underlying testing framework.  If done
appropriately, then running the generated tests on an arbitrary test framework might only require the hand coding of the appropriate base class and not require any changes to the generated tests.

Received on Monday, 11 June 2001 16:31:02 UTC