I have created TUSCANY-1356 for this cleanup and attached a patch
for the changes as described below.
Simon
Simon Nash wrote:
ant elder wrote:
On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote:
ant elder wrote:
> On 6/15/07, Simon Nash <[EMAIL PROTECTED]> wrote:
>
> <snip>
>
>
>>>> Testing that our sample client doesn't fail with an exception is
>>
>> >>> useful to us and may deserve a test in our integration test suite
(if
>> >>> we think that having a proper unit test case testing the bits and
>> >>> pieces in that module is not good enough), but I don't thing that
>> >>> it's interesting to keep it in the sample itself, as it's not
going
>> >>> to teach anything to an application developer looking at the
sample,
>> >>> and doesn't look like a "normal" unit test case.
>> >>>
>> >> Yes, agreed that this does not really belong in the samples. I
>> would be
>> >> inclined to put this test code in itest/samples, just to have the
>> build
>> >> confirm automatically that all the sample clients actually do run.
>> It's
>> >> good to have equivalent unit tests as well, but the samples are so
>> >> visible
>> >> that I think it's worth testing them explicitly.
>> >>
>> > [snip]
>> >
>> > This is still open. +1 to that suggestion, we do not pollute the
>> samples
>> > themselves with this kind of testing, we need to add new tests
under
>> > sca/itest/samples that verify that the samples' main methods do not
>> fail.
>> >
>> I volunteer to produce a patch for this. I'd like to get this into
0.91.
>
>
>
> If all this is going to do is check a sample main method runs
without an
> exception does it really matter if it gets in 0.91 or not?
>
The main benefit of getting it into 0.91 is to remove this test code
from
the sample itself, as it is making the sample slightly confusing.
Maybe I've misunderstood whats being proposed, which testcases are being
changed?
Someone has already replaced the client test code that previously
called main() with a copy of the JUnit test code from the extension
samples. So in the implementation-crud sample (using the new naming
convention) we have CRUDClient.java (correct) and CRUDTestCase.java
(incorrect, a copy of the same test from implementation-crud-extension,
and not testing any client code). This test does use the crud.composite
file from src/main/resources. If we had a non-sample itest to exercise
CRUDClient.java and crud.composite from this sample, we could eliminate
the duplicate copy of CRUDTestCase.java here. We could also eliminate
the dusplicate crud.composite file in implementation-crud-extension by
having the JUnit test in implementation-crud-extension use the
crud.composite file from implementation-crud.
Similarly, in the binding-echo-extension sample, under src/test we
have duplicates of the implementation code, composite file, and
JUnit test code from binding-echo. I'd like to remove this
duplicate code from binding-echo-extension, have the JUnit tests
in binding-echo-extension use this code from binding-echo, and
have a separate itest that excercises EchoBindingClient.java.
With this approach, all duplicate code is eliminated from the samples,
all sample code is tested either by sample JUnit tests or separate
itests, and the distinction between the extension and client/application
samples is much clearer.
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]
