RE: [MO-java-dev] 0.9 porting roadblock

[Tim M. <tim...@po...>]

patient: Ouch doctor it hurts when I hit myself....
dr: Don't do it then...

Barry - Its a bit unclear from your example (or lack of an example) but
MockOjects require an interface. Plain and simple... I don't recall the old
version supporting this? If it did it was accidental - as we advocate
programming by interface. In our experience programming by subclassing is
typically a smell, its hard to test - and compositional programming will in
the long term give you much clearer tests that are easier to refactor and
much clearer to test.

My advice is to convert your abstract class to an interface and proceed as
normal... The sun io classes are a classic example of how not to do it (I
figure they must be legacy code that predates them having interfaces in
java).

Tim

> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Barry Kaplan
> Sent: 21 May 2003 21:17
> To: mockobjects
> Subject: [MO-java-dev] 0.9 porting roadblock
>
>
> I've run into a problem which I do not [yet] know how to solve. I am
> testing an abstract class. Specifically, I am testing that the framework
> protocol is being adhered to. One of the means to do this is to test the
> that the abstract class invoke the appropriate abstract methods
> correctly. In 0.8, I did something like:
>
> private static AbstractClassUnderTest extends AbstractClass {
>
>      public CallSequence expectedAbstractMethod = ...
>
>      // was abstract in AbstraceClass
>      protected void abstractMethod(Object foo) {
>          expectedAbstractMethod.call(...);
>      }
> }
>
> Now the tests can create an AbstractClassUnderTest, testing that the
> concrete methods invoke abstractMethod() correctly.
>
> With 0.9, CallSequence requires a Mock in its call() method. But I
> cannot create a Mock because the abstractMethod() does not appear on any
> interface.
>
> One solution is to create an interface within the test class that just
> contains abstractMethod() so that a Mock can be created to satisfy
> CallSequence.
>
> Another solution is to refactor the abstract methods into a strategy
> interface, but I don't really want to that large of a design change just
> to upgrade to 0.9.
>
> Is there any way that anybody can think of? Is this a missing use case
> for dynamocks (ie, support for testing abstract classes)?
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.481 / Virus Database: 277 - Release Date: 13/05/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.481 / Virus Database: 277 - Release Date: 13/05/2003