Re: Some feedback on the DOM level 1 core tests

> >The one test == one Java file/class flows out of that since it is most
> >natural to do a case by case conversion using XSLT.  I
>
> Many-to-one isn't all that much harder, using XSLT's document() function.
> You'd want a top-level document which said which tests were to be built
> into each class, but that's easy enough.

But I've definitely followed the path of least resistance.

Obviously, I would avoid lots of tiny classes in an generic Java
application, but I like the current one test-> one class approach from an
production and organizational perspective.

Currently, in the ECMAScript transform, I'm creating one .js file per test.
I know that that would not be tolerable for deployment, so will look at some
means to combine them all at the end.

It's not that it couldn't be done, but I'm not convinced that it would be
beneficial in the long term and it is not beneficial in the very short term.

> >characterdataappenddatanomodificationallowederr
>
> Some compilers, in some languages, have trouble with long symbol names,
> even when the language permits them. I've seen some which simply ignore
any
> characters beyond the first  (or last) 32.  We may want to consider
> adopting a set of standard abbreviations to avoid that risk.  "
> chardataappendnomoderr" would cut the length by about 50%, though I grant
> that it's less readable for a novice.
>
> (Of course, readability of those names is rather marginal anyway. I
presume
> people have already considered camelCasedNames...?)

Unfortunately, I had to lose the camel case names that were in the test
definitions since the .ZIP file names were all lower case.  I've only had
nightmares trying the change the capitalization of filenames once they were
in CVS (note the screwy capitalization in the source for domunit).

I don't think it is essential that we try to summarize the case in the file
name, we should have enough test matrixes and other navigational tools that
test names can be more generic, like "characterdataappendnode3".  So for
future tests, I'd try to avoid the huge names.  I definitely got tired
typing "textsplittextnomodificationallowederr.xml" from the command line,
though I have  now committed it to muscle memory.

On another style point, the id's on asserts within a test could also be
shorter.  It is only necessary that they uniquely identify the assert within
the test, so that if a test fails, you know which assert failed and so that
we can associate metadata with an arbitrary assert.  I would recommend
something short, for example, "value", "type" or "throw".

Adding a optional shortName atttibute on the <test> element would allow us
to specify a shorter name if the monster names cause problems in code
production.

Received on Tuesday, 21 August 2001 14:02:35 UTC