Thanks for the detailed review and comments. My responses are inline.
Simon
Simon Laws wrote:
Hi, I was thinking about this problem the other way round
At the moment the binary distribution builds with the following structure
(taking binding-echo and simple-bigbank as two examples)
docs/
lib/
modules/
samples/
binding-echo
src/
main/
extension sample code
test/
java/
echo/
EchoBindingClient.java
EchoReferenceTestCase.java
EchoServiceTestCase.java
simple-bigbank/
src/
main/
java/
bigbank/
client/
BigBankClient.java
test/
java/
bigbank/
BigBankTestCase.java
So there are a number of issues we have been discussing
1/ Should there be JUnit tests in the samples.
2/ Should the mvn poms distributed with the binary distribution run the
sample client used by the Ant build instead of/as well as the JUnit test
3/ If you look at the binding-echo test (and the other extension example
tests) you see I put the clients used by ant in the test directory. This is
inconsistent with the rest of the samples but consistent with the desire to
demonstrate here how to build an extension, rather than how to build a
client.
My 2c on these
1/ I don't mind there being JUnit tests in the samples. I would bow to
consensus if it's generally thought that this complicates the first use
experience but as a java developer I know what a junit test is and it's
quite nice to have a test on which to base new tests that I may use with
any
changes I make
>
If it is desirable for the samples to provide a Junit-style template,
I could easily restructure the client code to follow the JUnit pattern of
having setUp(), testXXX() and tearDown() methods, invoked in turn by the
main() method.
I think the most important thing to decide is whether it's useful for
samples (as opposed to tests) to use JUnit directly or follow a JUnit-like
structure. I think we should go with the consensus on this. I don't think
we should clutter the samples with JUnit tests and non-JUnit clients that
both contain almost identical code.
2/ I think people running ant and mvn expect different things. I.e. having
mvn run the junit tests run is not unexpected to a maven user. We may
choose
to have the poms here run the ant client as well for completeness, e.g we
could engage your wrappers to do this.
>
This is what the sca/itest/samples poms are doing now in the code I posted.
I don't think this should becaome part of the sca/samples poms because it
pollutes the samples even more with artifacts that are there for test
purposes.
3/ This was the basis of my original question. The tests are not shipped in
the sample jars (I still need to find out why) to the effect is that the
client is missed from the sample jar and the three extension example tests
don't run out of the box. Due to the clients location I constructed the ant
scripts to build the test directory but had to filter out the unit tests
because JUnit does not ship. I would rather solve these problems by moving
the client code into main/ than removing the JUnit tests altogether.
It seems strange to me that we are including the jar files in the distro
but not the compiled standalone class files from src/test. The sample
pom.xml files solve this problem for maven users by forcing a recompile
of src/main and src/test before running the sample. (This makes it
pretty much pointless including the jars as part of the distributed
samples, as they always get rebuilt in this step). This doesn't require
the src/test classes to be part of the jar file. We could do the same in
build.xml for ant builds.
I took a look at the code. Some comments:
- I like the idea of the wrappers but I would maybe use them as well as the
junit tests rather than instead of.
>
It's a nuisance to maintain two sets of almost identical code, and rather
confusing for the user if we deliver both in the samples. I think it's
better to pick one flavour.
- The effect of removing the JUnit tests from the samples is that the
samples don't get tested anymore. Well not to the extent that the
assertions
that are currently included in the JUnit tests are exercised
Good point. For tests, this is important. For samples, displaying the
result to the console is better than running a silent assertion. It's
things like this that make me think we should make a distinction
between tests and samples. The wrapper approach does run all the
samples as part of the build, but doesn't currently do any validation
of the results.
- The itests aren't shipped at the moment in the binary release AFAIK so
the
maven based samples wouldn't be available. We could fix this of course but
would need discussion at this stage.
By maven-based samples I presume you mean samples that run when you
type mvn. With the code I checked in, mvn builds the samples but
doesn't run them. I'm confident that I could come up with a small pom
change that would run them as well (not within Junit), if that is desired.
There's a lot of discussion here. For clarity, here's what I think we
should do.
1. Have the ant and mvn sample builds do the same thing or close to
the same thing.
2. Have both of these run a non-junit sample client, after compiling
any necessary files first.
3. Divide sample code between src/main and src/test on the basis of what
makes most sense for the reader (remembering that these are samples).
For samples that build a jar that will be used as a runtime extension,
putting the test code for this extension into src/test and keeping
it out of the jar file seems best. For "standalone" samples that
consist of 100% test code, it seems best to avoid splitting this code
into src/main and src/test categories (pick either one). I don't
think there's any need to build a jar in these cases.
4. Don't ship pre-built jars for the samples. With mvn and ant scripts
provided for all the samples, it's really easy for anyone to build
the necessary class and jar files themselves.
5. Have the itest/samples module do automated testing of the samples
as part of the build, using Junit.
Comments much appreciated.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
