Comments inline.
Simon
Mike Edwards wrote:
Folks,
The real problem here is that the testcase for wsdl2java is cr*p. I'll
raise a JIRA to track this.
Basically, the testcase runs the wsdl2java tool a number of times and
produces some output. Nothing wrong with that, except that all that is
being tested is that the tool code can be invoked without getting an
exception.
There is *no* checking that what is produced by the tool makes any sense
at all. And in fact, the code produced DOESN'T make any sense - try
compiling it by hand.
So, this test needs changing and extending. There must be a test done
on the output code itself - ideally there should be an "expected output"
which is checked against the actual output.
One other point is that the generated code looks VERY poor - it's Java,
but not as you'd write it. For an SDO used by a method, for example,
instead of an import statement for the SDO class, followed by a variable
declaration using the class, the full path to the class is used on every
occasion it's referenced (YUK !!!!). Worse, the test doesn't actually
generate these SDO classes - hence the code won't compile since they
can't be found
These are very good points. I'd like to add one more observation.
I have never been very keen on test cases that generate and compare
their output against a "reference" version of what is expected,
rather than actually running the generated output as part of some
functional test.
The problem is that when small details of the output change, the
comparison fails, even when the output is still good. In my past
experience, this happens more often than the output changing from
good to bad. So the comparison gives more "false positives" than
"true positives", which is not very efficient. Also, the fix to
a "false positive" failure is usually to regenerate the reference
output using the new generator, and unless there's some way to
actually test the new reference output, there's a chance that the
new reference output could have bugs.
Testing the generated output in some functional way is a bit more
work initially, but this work is more than repaid in the longer
term by eliminating the "false positives" problem.
Simon
Yours, Mike.
Simon Laws wrote:
On Jan 11, 2008 4:50 AM, <[EMAIL PROTECTED]> wrote:
Author: lresende
Date: Thu Jan 10 20:50:35 2008
New Revision: 611046
URL: http://svn.apache.org/viewvc?rev=611046&view=rev
Log:
TUSCANY-1936
Modified:
incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
Modified: incubator/tuscany/java/sca/tools/wsdl2java/pom.xml
URL:
http://svn.apache.org/viewvc/incubator/tuscany/java/sca/tools/wsdl2java/pom.xml?rev=611046&r1=611045&r2=611046&view=diff
==============================================================================
--- incubator/tuscany/java/sca/tools/wsdl2java/pom.xml (original)
+++ incubator/tuscany/java/sca/tools/wsdl2java/pom.xml Thu Jan 10
20:50:35
2008
@@ -191,26 +191,6 @@
<build>
<plugins>
<plugin>
- <groupId>org.codehaus.mojo</groupId>
- <artifactId>build-helper-maven-plugin</artifactId>
- <version>1.0</version>
- <executions>
- <execution>
- <id>add-test-source</id>
- <phase>generate-sources</phase>
- <goals>
- <goal>add-test-source</goal>
- </goals>
- <configuration>
- <sources>
- <source>target/sdo-source</source>
-
<source>target/wsdl2java-source</source>
- </sources>
- </configuration>
- </execution>
- </executions>
- </plugin>
- <plugin>
<groupId>org.apache.tuscany.sdo</groupId>
<artifactId>tuscany-sdo-plugin</artifactId>
<version>1.0-incubating-SNAPSHOT</version>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Hi Luciano
It looks like this means that we are no longer trying to compile the
source
code that is generated as part of the generator test. I'm a little
concerned
that this means that we are not checking that the generator generates
valid
output. Looking at the tests though it doesn't seem that it does explicit
checks anyhow. So how about we build on your change here and do a textual
comparison of what was generated against what was expected to be
generated?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
