I'll add something to the Wiki about this.
Not sure where, maybe under FAQ. "what are some of the best practices
on testing your service contract implementations?"
i'll poke around to find a good spot for it.
thanks
much.
On Mon, 2004-01-26 at 17:29, Leo Simons wrote:
> korosh afshar wrote:
> >>Then I create unit tests for the to-be-created implementations using
> >>some mock objects framework for all dependencies. These test the work
> >>interface contract as I drew it.
> >
> > Do you use easymock or something else for this, cause it seems that it
> > does not test interfaces. Only if you have a implementation in place
> > can you use easymock to test the interface contract.
>
> you don't really ever want to test an interface IMHO, since an interface
> doesn't do anything. You want to test that a certain component
> implements the interface correctly. Take another look at the sample in
> the "unit testing woes" thread, for a bigger example of the following
> technique:
>
> public interface MyContract{ doBlah(); }
> public class MyContractImpl{ public doBlah() {} }
> public class MyContractImpl2{ public doBlah() {} }
>
> public abstract class AbstractMyContractTestCase extends TestCase
> {
> // ...
>
> /** concrete subclasses must provide an implementation of
> MyContract. */
> protected abstract MyContract getComponent();
>
> // ...
>
> // tests go here
> }
>
> public MyContractImplTestCase extends AbstractMyContractTestCase
> {
> protected MyContract getComponent()
> {
> return new MyContractImpl();
> }
>
> // MyContract is tested by superclass...
> }
>
> public MyContractImpl2TestCase extends AbstractMyContractTestCase
> {
> protected MyContract getComponent()
> {
> return new MyContractImpl2();
> }
>
> // MyContract is tested by superclass...
> }
>
> you can write the abstract test case first (though you can't run it),
> then create the concrete test cases just before you create your concrete
> implementations. You could test your tests like this:
>
> // don't test your tests!
> public MyContractTestCaseTestCase extends AbstractMyContractTestCase
> {
> protected MyContract getComponent()
> {
> MockControl.createControl(MyContract.class).getMock();
> }
>
> // MyContract is tested by superclass...the test will fail as
> // the mock doesn't work of course!
> }
>
> but there's not really any reason to once you get used to these kinds of
> techniques.
>
> BTW, there's books full of tips like this. Java Extreme Programming
> Cookbook is a nice one; the JUnit chapter, and some other excerpts are
> available for free online:
>
> http://www.oreilly.com/catalog/jextprockbk/chapter/ch04.pdf
> http://www.onjava.com/pub/a/onjava/excerpt/javaxpcookbook/index1.html
> http://www.onjava.com/pub/a/onjava/excerpt/javaxpcookbook/index2.html
> http://www.onjava.com/pub/a/onjava/excerpt/javaxpcookbook/index3.html
>
>
> >>I'd round of with a joke involving paper and coffee, but can't think of any.
>
> one is "brewing up" about coffee being in paper cups yet being afraid of
> the paper/coffee combo otherwise...and there must be something to say
> about me liking coffee so much while critizing beans [1]. But nothing
> really funny. I always envy funny people.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
