I think there is a difference in the way that we are looking at these
samples.
- We could consider that the samples are purely to show SCA running in
various scenarios and nothing more, i.e. anything extra such as sample tests
or extra build steps is superfluous.
- Alternatively we could consider the samples to be a demonstration of, not
only the function of the SCA runtime, but of how you might start to build
software that uses SCA, for example, you will likely need some tests and you
will want to be able to integrate the sample into your IDE of choice.
I have been thinking along the latter lines and stepping back I'm thinking
maybe we need to do more on testing rather than less, i.e. include a JUnit
target in the ant script. We also need some more IDE detail and I've already
marked this as a TODO in the top level samples README.
Anyhow I think this is why we seem to be coming at this from different
angles. So probably need others opinions to see which way to go.
Some more comments in line taking this into account.
On 5/11/07, Simon Nash <[EMAIL PROTECTED]> wrote:
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.
As I come from the second point of view I support having tests in the
samples. I can imagine that the clients and the JUnit tests would diverge to
alow for more imaginative sample outout than we have now.
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.gwe
> 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.
We can just flick the ant build over to make the run target depend on the
compile target to get the effect you have described.
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.
I would like to see the client and test code diverge to make the clients
more meaningful from a sample point of view.
- 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.
Think that sounds like a good idea but I include tests in that.
2. Have both of these run a non-junit sample client, after compiling
any necessary files first.
see 1
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.
I believe that the configuration we have now embodies this thinking
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.
I'm happy to ditch them and there is a very tiny change to the ant build if
they are not there.
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]
