mockobjects-java-users — For people who use the mock objects libraries

Re: [MO-java-users] Re: [MO-java-dev] Multiple method calls in any order?

[Barry K. <bk...@in...>]

>
>
>> I don't see how the ExpectationSet can do this. How to specify the 
>> mock return value for each key1/key2 combination? Can I use the 
>> Constraints with ExpectationSet (for mulitple arguments)?
>
>
> We're still thinking about this one, but it's an obvious direction to go. 


Seems that the dynamic mocksobjects handle this quite nicely. Here's 
what I did: The class I needed to test was an abstract class, so I could 
not use Mock or MockObject directly. Instead I mocked just the abstract 
hook methods required to the test the template methods. In the case of 
the 'getQuantity' hook method, I did:

    private CallSet expectedGetQuantity1 = new CallSet();

    // Just to provide an easier setup mechansim than having the test 
use the CallSet directly
    public void expectGetQuantity(Foo foo, Bar bar, Integer returnValue) {
        expectedGetQuantity1.expectReturn(
                new Constraint[]{P.eq(foo), P.eq(bar)}, returnValue);
    }

    public int getQuantity(Foo foo, Bar bar) {
        try
            return ((Integer) expectedGetQuantity1.call(new 
Object[]{foo, bar})).intValue();
        } catch (Throwable t) {
            // It kinda sucks that call() declares Throwable. Its really 
unecessary, since reflection will
            // throw the exception of the reflected. If the reflected 
method declares an exception
            // the mock method can pass it thru (or extract it from the 
exception the method.invoke() throws).
            throw new RuntimeException(t);
        }
    }

    public void verify() throws AssertionFailedError {
        expectedGetQuantity1.verify();
        ...
    }

>>
>> BTW, are there any other examples floating around (ie, projects that 
>> make extensive use of mockobjects)? The ones the distribution are ok, 
>> but not too extensive.
>
>
> not sure, but you could contribute some

Well, we have over 3000 unit tests for our system. I looked at 
mockobjects when we started, but instead decided to use the following 
very simple mock idiom (aka simplemock):

interface:
    public int getFoo(Bar bar);

mock:
    public boolean getFooCalled;
    public Integer getFooReturn;
    public Bar getFooBar;
    public int getFoo(Bar bar) {
        getFooCalled = true;
        getFooBar = bar;
        return getFooReturn.intValue();
    }

We have a code generator that creates this simple idiom from interfaces.

One of the big problem we ran into with mockobjects was the ability to 
get back the values passed into mocks (vs. just having the mock assert 
the values). For example, when testing a class that registers as a 
listener [with some mock], we often want to get hold of that listener 
instance (which may be the CUT or an inner of class of the CUT) and 
invoke methods on the listener so as to test the listening behavior. 
Implementations of Expectation all maintain the expected values as 
private and provide no accessors, making this type of usage impossible.

On the other hand, testing multiple calls to the mock within a single 
test using simplemock is painful. You have to explicity code in support. 
eg, Provide a collection for each argument and return values, or create 
a custom MockCall abstraction.

Back then I never really dug into the mockobjects code. Now, after 
having done so, I see that the mockobjects implementation is clean and 
simple, and most of limitations [for us] can easiliy be removed. We used 
easymock for a while, but had same issues as with mockobjects.

As for contributing. I certainly will. Both to the core and dynamic 
modules, and examples as we incrementally convert.

Thanks for the help Steve.

-bk

(I notice that all your responses post to both user and dev. Should that 
be the normal practice?)

[MO-java-users] Re: [MO-java-dev] Multiple method calls in any order?

[Steve F. <st...@m3...>]

Barry Kaplan wrote:
> Steve Freeman wrote:
> I'm still a bit confused. Consider:
> 
> public void class QuantityHolder {
>   public int getQuantity(Key key1, Key key1);
> }
> 
> public int sum(QuantityHolder holder) {
>   int result = holder.getQuantity("key1", "key2") + 
> holder.getQuantity("key3", "key4") + ...;
> }
> 
> I want to mock QuantityHolder. I want to ensure that sum() invoked the 
> getQuantity method twice, with the correct keys, but in any order.


depends on quite what you want to test, for example:

ExpectationSet keys;
public int getQuantity(Key key1, Key key2) {
   keys.addActual(key1);
   keys.addActual(key2);
}

would test that all four keys were used, but not the combinations. In 
practice, would that satisfy you that you'd covered the bases?

alternatively, how about a constraint:
   P.or(
     P.and(P.eq("key1"), P.eq("key2")),
     P.and(P.eq("key3"), P.eq("key4")));

which tests that only the right combinations are passed through.

If the arguments are always in the same order, you could try:

ExpectationSet keys;
public int getQuantity(Key key1, Key key2) {
   keys.addActual(key1 + key2);
}

Finally, if the arguments can come in any order but the pairs matter, I 
think you could try:

ExpectationSet keys;
public int getQuantity(Key key1, Key key2) {
   Set keySet = new HashSet();
   keySet.add(key1);
   keySet.add(key2);
   keys.addActual(keySet);
}

> I don't see how the ExpectationSet can do this. How to specify the mock 
> return value for each key1/key2 combination? Can I use the Constraints 
> with ExpectationSet (for mulitple arguments)?

We're still thinking about this one, but it's an obvious direction to go.

> 
> -bk
> 
> BTW, are there any other examples floating around (ie, projects that 
> make extensive use of mockobjects)? The ones the distribution are ok, 
> but not too extensive.

not sure, but you could contribute some...

S.

[MO-java-users] Re: [MO-java-dev] Question about MethodExpectation

[Steve F. <st...@m3...>]

Use expectCall to specify that the method should be called during the 
test and fail if it doesn't happen. Usually use setupCall to, um, setup 
return values when a method is called, but we don't care if it is 
called or what the paramaters are. Use the setup to get the code to work 
so you can get on to whatever else it is you want to verify. This can 
sometimes be useful if you want a single setup in a mock that will be 
used in several different tests.

S.

Barry Kaplan wrote:
> When should expectCall vs setupCall be used? Seems the only differnce is 
> that setupCall creates a new ExpectationValue (overriding the existing 
> instance), were expectCall sets the value of the existing instace.
> 
> -bk
> 
> ----
>   private ExpectationValue wasCalled;
> 
>   public MethodExpectation(String aName) {
>       name = aName;
>       initializeWasCalled();
>   }
> 
>   public void expectCall(MockCall aCall) {
>       mockCall = aCall;
>       wasCalled.setExpected(true);
>   }
> 
>   public void setupCall(MockCall aCall) {
>       mockCall = aCall;
>       initializeWasCalled();
>   }
> 
>   private void initializeWasCalled() {
>       wasCalled = new ExpectationValue(name + " was called");

[MO-java-users] Re: [MO-java-dev] Multiple method calls in any order?

[Steve F. <st...@m3...>]

Thanks for your proposal in another message.

You might also consider combining the dynamic mock with a hand-rolled 
mock using the ExpectationSet, e.g.

public void MockFoo extends Mock {
   ExpectationSet values = new ExpectationSet("values);

   public void addValue(Value aValue) { // override
     values.addActual(aValue);
   }

   public void verify() {
     super.verify();
     values.verify();
   }
}

The hand-coded addValue() method will be picked up before the dynamic 
implementation.

S.

Barry Kaplan wrote:
> I'm trying to test methods that create sums by invoking other methods. I 
> can setup the other methods correctly, but the setup of the mock method 
> calls is always sensitive to the order in which they are called. For the 
> method under test, this is not a requirement. Is there any mechanism for 
> setting up a CallSequence to not care about the order, but still ensure 
> that the total number of calls were made and the parameters were 
> correct. (I suppose it might have to give each method a shot, and only 
> fail if all fail to verify?)

[MO-java-users] Re: [MO-java-dev] [PATCH] MockHttpServletRequest.java 0.07

[Steve F. <ste...@m3...>]

I've checked in implementations of this for the j2ee 1.3.1 
version. I've also realised that we need to do something to get 
the same effect into the j2ee 1.2.1 version as well, preferably 
be pulling out the common code. Any suggestions for an easier way 
  gratefully received.

Steve


Stefan Gruendel wrote:
> Hi,
> 
> implemented some methods I was missing.
> 
> Best regards, Stefan
> 
> 
> --- MockHttpServletRequest.java.original	Tue Sep 10 10:40:32 2002
> +++ MockHttpServletRequest.java	Fri Nov  8 13:05:37 2002
> @@ -23,8 +23,11 @@
>      private String myContentTypeToReturn;
>      private String myContextPath;
>      private String myPathInfo;
> +    private String myQueryString;
>      private String myRemoteAddress;
>      private String myRequestURI;
> +    private String myScheme;
> +    private String myServerName;
>      private String myMethod;
>      private ServletInputStream myInputStream;
>      private Principal myUserPrincipal;
> @@ -183,9 +186,12 @@
>          return null;
>      }
>  
> +    public void setupGetQueryString(String aQueryString) {
> +        this.myQueryString = aQueryString;
> +    }
> +
>      public String getQueryString() {
> -        notImplemented();
> -        return null;
> +        return myQueryString;
>      }
>  
>      public BufferedReader getReader() throws IOException {
> @@ -235,14 +241,20 @@
>          return myRequestURI;
>      }
>  
> +    public void setupGetScheme(String aScheme) {
> +        myScheme = aScheme;
> +    }
> +
>      public String getScheme() {
> -        notImplemented();
> -        return null;
> +        return myScheme;
> +    }
> +
> +    public void setupGetServerName(String aServerName) {
> +        myServerName = aServerName;
>      }
>  
>      public String getServerName() {
> -        notImplemented();
> -        return null;
> +        return myServerName;
>      }
>  
>      public int getServerPort() {
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: See the NEW Palm 
> Tungsten T handheld. Power & Color in a compact size!
> http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev

[MO-java-users] Re: Mock Objects Bug?

[Steve F. <ste...@m3...>]

Thanks for your example. I'm assuming that you're doing the getString() 
so that you can check for null values, which getInt() won't tell you. 
It's true that our current implementation cannot handle different 
returns for the same index, we haven't had to so far. Looking at the 
JDBC spec, there's a wasNull() call on a result set which tells you if 
the last retrieved value was null. Would that be a better solution? You 
could then override wasNull() on the MockResultSet you're using and 
return a boolean as appropriate.

Alternatively, if you feel like changing the code in MockResultSet, go 
ahead. We don't believe we can cover all the bases in something as large 
as the JDBC library and that's what CVS merge is for.

Steve

Mark Harper wrote:

>Hi there,
>
>Sanjay Chakravarty told me that that you might be interested in a problem
>I've run into using com.mockobjects.sql.MockSingleRowResultSet.
>See the attached test class for a full description...
>
>I realize that the code in countSomething() is redundant, and probably
>should be simplified.  But the question is, should this be considered a
>bug in the MockResultSet implementation?
>If I am constrained not to change this code, how might I work around this?
>
>Many Thanks,
>_Mark Harper
>
>
>  
>
>------------------------------------------------------------------------
>
>package mockobjectstest;
>
>import com.mockobjects.sql.MockConnection;
>import com.mockobjects.sql.MockPreparedStatement;
>import com.mockobjects.sql.MockSingleRowResultSet;
>import com.mockobjects.sql.MockStatement;
>import java.lang.Exception;
>import java.sql.Connection;
>import java.sql.ResultSet;
>import java.sql.PreparedStatement;
>
>public class ResultSetBugTest
>{
>    /*
>     * The following code works on a java.sql.ResultSet.
>     * With a MockResultSet, however, I can't get it to work.
>     */
>    public static int countSomething(Connection conn)
>    {
>        PreparedStatement   pstmt = null;
>        int resultCount = 0;
>
>        try {
>            pstmt = conn.prepareStatement("SELECT COUNT(*) FROM A_TABLE");
>
>            ResultSet rs = pstmt.executeQuery();
>
>            if (rs.next())
>            {
>              if (rs.getString(1) != null) //line 1
>              {
>                resultCount = rs.getInt(1); //line 2
>              }
>            }
>        }
>        catch (java.sql.SQLException e)
>        {
>            e.printStackTrace();
>        }
>        return resultCount;
>    }
>
>    /*
>     * If I set up a Mock Result set with an Integer value for the count...
>     */
>    public static void testSetupOne()
>    {
>        MockConnection mockConnection = new MockConnection();
>        MockPreparedStatement mockPreparedStatement  = new MockPreparedStatement();
>        mockConnection.setupStatement( mockPreparedStatement );
>        mockConnection.addExpectedPreparedStatement( mockPreparedStatement );
>        MockSingleRowResultSet mockResultSet = new MockSingleRowResultSet();
>
>        Integer countValue = new Integer(1);
>        Integer[] resultValues = new Integer[] {countValue};
>        mockResultSet.addExpectedIndexedValues( resultValues );
>        mockPreparedStatement.addResultSet( mockResultSet );
>        countSomething( mockConnection );
>    /*
>     * I get a...
>     *  java.lang.ClassCastException: java.lang.Integer
>     *      at com.mockobjects.sql.MockResultSet.getString(MockResultSet.java:306)
>     * at //line 1 above.
>     */
>    }
>
>
>    /*
>     * If I set up the Mock Result set with a String value...
>     */
>    public static void testSetupTwo()
>    {
>        MockConnection mockConnection = new MockConnection();
>        MockPreparedStatement mockPreparedStatement  = new MockPreparedStatement();
>        mockConnection.setupStatement( mockPreparedStatement );
>        mockConnection.addExpectedPreparedStatement( mockPreparedStatement );
>        MockSingleRowResultSet mockResultSet = new MockSingleRowResultSet();
>
>        String countValue = "1";
>        String[] resultValues = new String[] {countValue};
>        mockResultSet.addExpectedIndexedValues( resultValues );
>        mockPreparedStatement.addResultSet( mockResultSet );
>        countSomething( mockConnection );
>    /*
>     * I get a...
>     *  java.lang.ClassCastException: java.lang.String
>     *      at com.mockobjects.sql.MockResultSet.getInt(MockResultSet.java:266)
>     * at //line 2 above.
>     */
>    }
>
>    public static void main (String args[])
>    {
>        System.out.println("Trying Test One");
>        try
>        {
>            testSetupOne();
>        }
>        catch (Exception e)
>        {
>            e.printStackTrace();
>        }
>
>        System.out.println("Trying Test Two");
>        try
>        {
>            testSetupTwo();
>        }
>        catch (Exception e)
>        {
>            e.printStackTrace();
>        }
>
>
>    }
>}
>
>  
>

[MO-java-users] Re: [MO-java-dev] Release 0.07?

[Steve F. <ste...@m3...>]

Happy to have you on board.

Pattern 2 is the correct one. The idea of setting expectations is so 
that the test can fail at the right time, when the actual event occurs. 
We can't do that if you don't specify your requirements before you start.

We know that the javadoc is a mess, but we talk about this pattern at 
least in the Endo-testing paper. Is it not clear?

S

Immanuel, Gidado-Yisa wrote:

>(Appologies if this should go to the user list, but
>that list has been dormant for a little while, so
>I'm headed straight to the source)
>
>This has taken me about an 1 1/2 to figure out (thank
>goodness for the code).  In my test case I have:
>
>  1.    handler.log(val);
>  2.    mock.setExpectedLogMessage(val);
>  3.    mock.verify();
>
>where the handler knows about the mock.  What happens is
>that line 1 eventually calls mock.log() which then calls
>mock.logMessage.setActual().  setActual looks to see if
>it should verify...finds no expectations...so skips it.
>
>Line 2 sets the expected value which eventually calls
>ExpectationValue.setExpected() which calls
>AbstractExpectation.setHasExpectations() which does the
>not so obvious:
>
>   AbstractExpectation.clearActual()
>
>So Line 2 ends up clearing whatever is set in Line 1.  The
>only usage pattern that works is to setExpected() before setActual():
>
>  1.    mock.setExpectedLogMessage(val);
>  2.    handler.log(val);
>  3.    mock.verify();
>
>This was not clear anywhere in the articles or javadoc.  Perhaps
>you could add this to the FAQ page.  I assume there is a very
>good reason why clearActual() is necessary in
>setHasExpectations()...I'm very new to all this, so if you don't
>mind educating me a little, I would love to know.
>
>Thanks,
>Gidado
>
>  
>

[MO-java-users] RE: [MO-java-dev] SuiteBuilder?

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

Don't speak so soon - the one in eclipse is pretty poor... I had high hopes
too until I used it this morning and it hardly did anything.

That said - it probably doesn't belong in the mock objects build... I've
also been experimenting with rebuilding the junit plugin with the MO assert
methods built into it - if I can get used to this cvs stuff and how to
submit things I'll see about getting them rolled into junit.

Tim

-----Original Message-----
From: moc...@li...
[mailto:moc...@li...]On Behalf Of
Steve Freeman
Sent: 21 October 2002 21:29
To: mockobjects users; MockObjects
Subject: [MO-java-dev] SuiteBuilder?


Is anyone still using SuiteBuilder to assemble JUnit tests?

It strikes me that JUnit is much improved in this area and we could do away
with it.

Steve




-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of  Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote
_______________________________________________
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.404 / Virus Database: 228 - Release Date: 15/10/2002

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.404 / Virus Database: 228 - Release Date: 15/10/2002

[MO-java-users] SuiteBuilder?

[Steve F. <st...@m3...>]

Is anyone still using SuiteBuilder to assemble JUnit tests?

It strikes me that JUnit is much improved in this area and we could do away
with it.

Steve

[MO-java-users] Re: [MO-java-dev] Avoiding loops in Verifier again.

[Steve F. <st...@m3...>]

From: "Simon Levitt" <sim...@uk...>
> On Sunday 29 September 2002 17:58, Steve Freeman wrote:
> > I'd like to propose that a Verifiable loop is a code smell which
> > implies that something has become too complicated, so we shouldn't
> > compensate for it.
> >
> > Thoughts?
> >
> As I introduced the code that tried to cope with smell (in a simple way -
> through the static Vector) I suppose I should comment.
>
> I think you may be over generalising here in that MockObjects currently
> only has one place where a child requires a reference to its parent
> (which has a reference to its children), and you're trying to avoid the
> potential problem by defining it as a smell.
>
> The aim of MockObjects, surely?, is to support anything that can be thrown
> at it. Isn't just ignoring this kind of 'problem' limiting? The
> MockObjects must be as complicated as the thing they are trying to Mock.
> Ignoring parts of industry standard interfaces sounds like a death
> sentence to me...

Not exactly. We also use complexity in testing as a hint that our design
might be getting out of hand. For example, what kind of code would get a
statement from a connection, and then the connection from the statement, in
the same fragment? Sounds like there are two pieces there that could be
tested seperately. In that case, you should have different mock clusters set
up for each piece and there should be no recursion. The problem then becomes
one of making test setup lightweight and easy, rather than making the mock
complete.

We need to find ways for people to do everything they need to, but that
doesn't mean that we need a single mock implementation for all possible
tests. Increasingly, I find myself creating a null implementation of an
interface and then overriding the methods I need for a particular test in an
anonymous class. One of the essential points about testing with mocks is
that the mocks must be simple enough that the failures will always be in the
target code and that this should be obvious. Our mock implementations are
now getting to the point where they need tests themselves and that bothers
me.

Hmmm. Perhaps we should be gathering patterns of use for each library and
writing some canned setups for each one?

> Having ideals is fine, sticking them to the end without compromise is
quite often stupid.

Easy now, in a moment one of us will use the N?zi word and the game will be
over ;-)

> Also in certain cirumstances Verifier can be involved in mantaining the
> infinate loops and inherant stack overflow that occurs in these
> circumstances, is this the sort of image a project that should be capable
> of being used in the commerce commercial quality projects be projecting?

Don't understand this.

> As far as the JDBC problem goes could it be gotten around by storing the
> parent references as the implemented interface rather than the Mock
> reference?

True, or a simple null stub. Depends on what the test needs.

Steve

[MO-java-users] Re: [MO-java-dev] Avoiding loops in Verifier again.

[Simon L. <sim...@uk...>]

On Sunday 29 September 2002 17:58, Steve Freeman wrote:
> I'd like to propose that a Verifiable loop is a code smell which
> implies that something has become too complicated, so we shouldn't
> compensate for it.
>
> Thoughts?
>
As I introduced the code that tried to cope with smell (in a simple way -=20
through the static Vector) I suppose I should comment.

I think you may be over generalising here in that MockObjects currently=20
only has one place where a child requires a reference to its parent=20
(which has a reference to its children), and you're trying to avoid the=20
potential problem by defining it as a smell.

The aim of MockObjects, surely?, is to support anything that can be thrown=
=20
at it. Isn't just ignoring this kind of 'problem' limiting? The=20
MockObjects must be as complicated as the thing they are trying to Mock.=20
Ignoring parts of industry standard interfaces sounds like a death=20
sentence to me...=20

Having ideals is fine, sticking them to the end without compromise is=20
quite often stupid.

Also in certain cirumstances Verifier can be involved in mantaining the=20
infinate loops and inherant stack overflow that occurs in these=20
circumstances, is this the sort of image a project that should be capable=20
of being used in the commerce commercial quality projects be projecting?

As far as the JDBC problem goes could it be gotten around by storing the=20
parent references as the implemented interface rather than the Mock=20
reference?

Simon.,
(My thoughts - NOT my employers)

[Mockobjects-java-users] Avoiding loops in Verifier again.

[Steve F. <st...@m3...>]

I've done a little tidy up in the Verifier. No major functional changes yet,
but I've made verifyField() private  -- unless someone wants it back.

That static vector still gets up my nose, I've done some refactorings
towards getting away from it but got a bit stuck, so I'd like to poll people
again.

It seems that the principal need for this is in the JDBC library where, for
example, a mock statement references a mock connection and vice versa. I
can't help feeling that we've let our desire for generality get out of hand
and that we really shouldn't be writing code that daisy-chains statements
and connections (or whatever). Similarly, I doubt that we should have one
setup routine for a "cluster" of related objects, we should have several to
implement multiple situations.

I'd like to propose that a Verifiable loop is a code smell which implies
that something has become too complicated, so we shouldn't compensate for
it.

Thoughts?

Steve

- - - - - - - - - - - - - - -
Steve Freeman   st...@m3...
Programme chair OT2003. http://www.ot2003.org

"Nonsense is just nonsense, but the study of nonsense is science."

Re: [Mockobjects-java-users] Visit files and subdirectories

[Jeff M. <je...@mk...>]

Take a look at the alt.io.File interface
(http://www.mockobjects.com/javadoc/1.3/). It does mean you have to use
the alt.io classes in your project but it makes your code testable.

On Fri, 2002-09-13 at 11:20, Alain Ravet wrote:
> So many tools, so little time; I browsed the examples, but didn't find 
> an solution to my problem :
> 
> Develop test-first a solution to
> "Given a directory path, /zip/ all its included file and subdirectories".
> 
> Can mockobject simulate the directories and files behaviour for this to 
> work?
> 
> 
> Alain Ravet
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

[Mockobjects-java-users] Visit files and subdirectories

[Alain R. <ala...@wa...>]

So many tools, so little time; I browsed the examples, but didn't find 
an solution to my problem :

Develop test-first a solution to
"Given a directory path, /zip/ all its included file and subdirectories".

Can mockobject simulate the directories and files behaviour for this to 
work?


Alain Ravet

[Mockobjects-java-users] Re: [MO-java-dev] verify()ing object hierachies.

[Steve F. <st...@m3...>]

From: "Simon Levitt" <sim...@uk...>
> I've been looking into the sql Mock objects, and now in particular how to
> verify the Expectations that have been set up.
>
> >From what I understand the only way to do this currently is to manually
> code a call to verify on every MockConnection, MockStatement derived, and
> MockResultSet derived, object from the test code.
>
> It strikes me it would be must nicer to be able to call verify on the
> MockConnection and it ripple through the heirachy of objects.

That's an interesting idea. Jeff has been working on "mock kits" to set up
clusters of related objects, so that might be relevant. Don't forget the
Verifier object that  will verify all the appropriate instance variables of
an object.

> I've started looking into this, alongside other changes I'd like to
> present in the near future, and a way of doing it would be to change
> ExpectationMap and ReturnObjectList to allow the verifying their
> contained objects by adding a flag to enable/disable the functionality
> (with disable being the default). ReturnObjectList would have to keep
> hold of returned objects in order to do this successfully.

I'd like to see some concrete examples, especially for ExpectationMap which
is, itself a verifiable. It's sounds like some of your tests may be going
too deep. You can overspecify, as well as underspecify.

Steve

[Mockobjects-java-users] Patch to add getContextPath support to MockHttpServletRequest

[Chris N. <ch...@si...>]

Thanks,
Chris

Index: MockHttpServletRequest.java
===================================================================
RCS file: /cvsroot/mockobjects/mockobjects-java/src/j2ee/1.3/com/mockobjects/servlet/MockHttpServletRequest.java,v
retrieving revision 1.8
diff -c -r1.8 MockHttpServletRequest.java
*** MockHttpServletRequest.java	27 Aug 2002 16:38:17 -0000	1.8
--- MockHttpServletRequest.java	9 Sep 2002 21:31:28 -0000
***************
*** 21,26 ****
--- 21,27 ----
      private Dictionary myHeaders = new Hashtable();
      private HttpSession myHttpSession;
      private String myContentTypeToReturn;
+     private String myContextPath;
      private String myPathInfo;
      private String myRemoteAddress;
      private String myRequestURI;
***************
*** 91,98 ****
      }
  
      public String getContextPath() {
!         notImplemented();
!         return null;
      }
  
      public Cookie[] getCookies() {
--- 92,102 ----
      }
  
      public String getContextPath() {
!         return myContextPath;
!     }
! 
!     public void setupGetContextPath(String contextPath) {
!         myContextPath = contextPath;
      }
  
      public Cookie[] getCookies() {
***************
*** 352,355 ****
      public Map getParameterMap() {
          return null;
      }
! }
\ No newline at end of file
--- 356,359 ----
      public Map getParameterMap() {
          return null;
      }
! }

Re: [Mockobjects-java-users] Struts test case/mock problem

[Ted H. <hu...@ap...>]

I think this is coming out of some classes in the Struts codebase. I'll 
see about getting us (Struts) nstandardized on the MockObjects api.

- Ted.


Jeff Martin wrote:

> Looks like encodeRedirectUrl has not been written, so it's just throwing
> an UnsupportedOperationException
> 
> BTW. as far as I know we're not involved in servletunit although we do
> have a similar set of mocks.
> 
> 
> On Tue, 2002-09-03 at 16:32, Oren Gross wrote:
> 
>>Anyone familiure with the next exception?
>>
>>java.lang.UnsupportedOperationException: encodeRedirectUrl operation is not
>>supported!
>>	at
>>servletunit.HttpServletResponseSimulator.encodeRedirectURL(HttpServletRespon
>>seSimulator.java:199)
>>	at
>>org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja
>>va:1748)
>>	at
>>org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
>>	at
>>org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
>>	at
>>servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:
>>254)
>>	at
>>com.mercury.topaz.admincenter.app.db.DbListActionTest.testPerformClearDb(DbL
>>istActionTest.java:37)
>>	at
>>com.mercury.topaz.admincenter.app.db.DbListActionTest.main(DbListActionTest.
>>java:44)
>>______________________________
>>Oren Gross, Software Developer
>>Mercury Interactive, APM - R&D
>>+972-3-5399407, og...@me...
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by: OSDN - Tired of that same old
>>cell phone?  Get a new here for FREE!
>>https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
>>_______________________________________________
>>Mockobjects-java-users mailing list
>>Moc...@li...
>>https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
>>


-- 
Ted Husted, Husted dot Com, Fairport NY US
co-author, Java Web Development with Struts
Order it today:
http://husted.com/struts/book.html

Re: [Mockobjects-java-users] Struts test case/mock problem

[Jeff M. <je...@mk...>]

Looks like encodeRedirectUrl has not been written, so it's just throwing
an UnsupportedOperationException

BTW. as far as I know we're not involved in servletunit although we do
have a similar set of mocks.


On Tue, 2002-09-03 at 16:32, Oren Gross wrote:
> Anyone familiure with the next exception?
> 
> java.lang.UnsupportedOperationException: encodeRedirectUrl operation is not
> supported!
> 	at
> servletunit.HttpServletResponseSimulator.encodeRedirectURL(HttpServletRespon
> seSimulator.java:199)
> 	at
> org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja
> va:1748)
> 	at
> org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
> 	at
> org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
> 	at
> servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:
> 254)
> 	at
> com.mercury.topaz.admincenter.app.db.DbListActionTest.testPerformClearDb(DbL
> istActionTest.java:37)
> 	at
> com.mercury.topaz.admincenter.app.db.DbListActionTest.main(DbListActionTest.
> java:44)
> ______________________________
> Oren Gross, Software Developer
> Mercury Interactive, APM - R&D
> +972-3-5399407, og...@me...
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

[Mockobjects-java-users] Struts test case/mock problem

[Oren G. <og...@me...>]

Anyone familiure with the next exception?

java.lang.UnsupportedOperationException: encodeRedirectUrl operation is not
supported!
	at
servletunit.HttpServletResponseSimulator.encodeRedirectURL(HttpServletRespon
seSimulator.java:199)
	at
org.apache.struts.action.ActionServlet.processActionForward(ActionServlet.ja
va:1748)
	at
org.apache.struts.action.ActionServlet.process(ActionServlet.java:1595)
	at
org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:509)
	at
servletunit.struts.MockStrutsTestCase.actionPerform(MockStrutsTestCase.java:
254)
	at
com.mercury.topaz.admincenter.app.db.DbListActionTest.testPerformClearDb(DbL
istActionTest.java:37)
	at
com.mercury.topaz.admincenter.app.db.DbListActionTest.main(DbListActionTest.
java:44)
______________________________
Oren Gross, Software Developer
Mercury Interactive, APM - R&D
+972-3-5399407, og...@me...

Re: [Mockobjects-java-users] RE: java.lang.Proxy

[Steve F. <st...@m3...>]

From: "Oren Gross" <og...@me...>
> The biggest problem with Mock Objects, is that it assumes that each tested
> method, receives the mockable object as a parameter. I know that designers
> believe that this is the right way to do stuff, but:
> 1. It is not always possible.
> 2. Sometimes you test old code.
> 3. This argument is questionable.

Not exactly, our point is that the mockable object should be substitutable
_somehow_, maybe during construction, maybe via a setter, maybe as a
parameter. If you're working with horrible old code, then introducing
interfaces that can be mocked is often the only way to test chunks of
functionality.

S.

[Mockobjects-java-users] RE: java.lang.Proxy

[Oren G. <og...@me...>]

The biggest problem with Mock Objects, is that it assumes that each tested
method, receives the mockable object as a parameter. I know that designers
believe that this is the right way to do stuff, but:
1. It is not always possible.
2. Sometimes you test old code.
3. This argument is questionable.

If you are lucky, you were using a factory where you didn't implement your
method as 'expected'. 
You EasyMock is a classic solution where a developer is using a factory, and
I think such an example would be a great added value.
If you don't think otherwise, I would be happy to supply you with some of my
code.
Thanks

______________________________
Oren Gross, Software Developer
Mercury Interactive, APM - R&D
+972-3-5399407, og...@me... <mailto:og...@me...> 
 


-----Original Message-----
From: Tammo Freese [mailto:tam...@of...]
Sent: Monday, September 02, 2002 5:54 PM
To: Oren Gross
Subject: Re: java.lang.Proxy


Oren Gross wrote:
> It works!

Great!

If you encounter any additional problems, please let me know.

Greetings,

-
Tammo Freese

[Mockobjects-java-users] question for the people who are using StrutsTestCase.

[Oren G. <og...@me...>]

Few question for the people who are using StrutsTestCase.
1. Can the Struts ActionServlet handle web-inf as WEB-INF?
2. How do I know if it found the file, and the requested path info?
Thanks
______________________________
Oren Gross, Software Developer
Mercury Interactive, APM - R&D
+972-3-5399407, og...@me...

RE: [Mockobjects-java-users] MockHttpSession's getAttributeNames( ) returns null

[Oren G. <og...@me...>]

well, I just implemented my own:
public class TACHttpSession extends MockHttpSession {

  public TACHttpSession() {
    super();
    setupServletContext(new MockServletContext());
  }
  public TACHttpSession(MockServletContext context) {
    super();
    setupServletContext(context);
  }
  public Enumeration getAttributeNames() {
    return new Vector(attributes.keySet()).elements();
  }
}

______________________________
Oren Gross, Software Developer
Mercury Interactive, APM - R&D
+972-3-5399407, og...@me... <mailto:og...@me...> 
 


-----Original Message-----
From: Jeff Martin [mailto:je...@mk...]
Sent: Tuesday, August 27, 2002 4:11 PM
To: Mockobjects "Users (E-mail)
Subject: Re: [Mockobjects-java-users] MockHttpSession's getAttributeNames()
returns null


Should have throw an NotImplemented exception. I've added
setupGetAttribute names to cvs

On Tue, 2002-08-27 at 15:35, Oren Gross wrote:
> Hi there, I am using the mockobjects-j2ee1.3.jar's MockHttpSession in the
> following way, but get a null enumaration.
> Any ideas? Thanks
>  
> MockHttpSession _session = new MockHttpSession(); //empty session
> ...
> _session.setAttribute("now", new Date());
> Enumeration e = _session.getAttributeNames(); //e is null!!!
> ______________________________
> Oren Gross, Software Developer
> Mercury Interactive, APM - R&D
> +972-3-5399407, og...@me... <mailto:og...@me...> 
> 
>  
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com



-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Mockobjects-java-users mailing list
Moc...@li...
https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users

Re: [Mockobjects-java-users] MockHttpSession's getAttributeNames() returns null

[Jeff M. <je...@mk...>]

Should have throw an NotImplemented exception. I've added
setupGetAttribute names to cvs

On Tue, 2002-08-27 at 15:35, Oren Gross wrote:
> Hi there, I am using the mockobjects-j2ee1.3.jar's MockHttpSession in the
> following way, but get a null enumaration.
> Any ideas? Thanks
>  
> MockHttpSession _session = new MockHttpSession(); //empty session
> ...
> _session.setAttribute("now", new Date());
> Enumeration e = _session.getAttributeNames(); //e is null!!!
> ______________________________
> Oren Gross, Software Developer
> Mercury Interactive, APM - R&D
> +972-3-5399407, og...@me... <mailto:og...@me...> 
> 
>  
-- 
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com

Re: [Mockobjects-java-users] Re : Feature-Request

[Jeff M. <je...@mk...>]

It's something we've been thinking about. Another example is testing
servlets.

To run a servlet you need a number of objects request, response,
session, context, request dispatcher... With tags there's even more. I
started use some a common testcase for these which populates variables
with these mocks and sets up the relationships between them.

I think now my approach would be to have a test helper class which has
these objects in it.

public void testSomeServlet(){
	SomeServlet someServlet =3D new SomeServlet();
	ServletTestHelper testHelper =3D new ServletTestHelper();

	testHelper.getRequest().setExpectedGetParameter("something");
	testHelper.getSession()...

	testHelper.testInitServlet(servlet);
	testHelper.testDoPost(servlet);

	testHelper().getRequest().verify();
	testHelper().getSession().verify();
}

It's not necessarily clever or going to cover all cases but it's a help.
JDBC stuff might be a bit more difficult because there's more ways in
which it can be used.


On Fri, 2002-08-23 at 14:44, Gilles DODINET wrote:
> im really sorry about the previous post. this is the right one. could the=
 moderator please  delete the previous one ?
>=20
>=20
> ---- Message starts here ---
>=20
> no, thats not what i mean : my MockConnection is a
> MockConnection just as it is now. Although my
> MockConnectionFactory would create the
> MockPreparedStatement and the MockPreparedStatementFactory
> would create the MockResultSet. calling verify on
> myMockConnection would call verify myMockPreparedStatement
> which in turn would verify myMockResultSet. the goal under
> the request is to statically describe a reusable test
> configuration, i.e. describe the configuration of mock
> components in a xml file - in a kilim way
> (http://www.objectweb.org/kilim). so instead of creating
> and configuring MockObjects directly in the TestCase i
> would delegate creation and configuration through a call of
> type myMockConnection =3D
> myConnectionFactory.getConnection("MockConnectionThatBehaves
> LikeThat"); and i wouldnt worry about instantiating or
> configuring neither the MockResultSet nor the
> MockPreparedStatement anymore.
> i think this is relevant since behaviour is often shared.
> This could allow me to call the verify method *just* on
> myMockConnection.
> that approach is arguable, like i said in my previous post,
> since it implies that the TestCase lost a bit of control
> upon the test environment configuration. however i have the
> intuition that it would be of much help. And also even if
> you dont agree with the cascading verify idea, perhaps you
> would with the factory one (i found kilim to be very
> useful) ? anyway im always interested in your point of
> view.
>=20
> thanks for your reply,
>=20
> -- gd
>=20
>=20
> >Messsage du 23/08/2002 12:30
> >De : Nat Pryce <nat...@b1...>
> >A : Gilles DODINET <rh...@wa...>
> >Copie =E0 :
> >Objet : Re: [Mockobjects-java-users] Feature-request=20
> >
> > If I understand you, you want your MockConnection to
> create your
> > MockPreparedStatement and MockResultSet objects. I think
> that's the
> > wrong approach because you are putting too much real
> implementation into
> > your mock objects.
> >
> > Instead, create a MockConnection a MockPreparedStatement,
> keep
> > references both objects in variables in your test, tell
> the connection
> > to return the mock statement when createStatement() (or
> whatever) is
> > called, and verify both objects at the end of the test.
> >
> > Cheers,
> > Nat.
> >
> > On Fri, 2002-08-23 at 12:00, Gilles DODINET wrote:
> > > Hi,
> > >
> > > I think MockObjects are missing a feature very useful
> when working with factories. imho they should follow the
> Composite pattern. For instance, let's say i wanna use a
> MockConnection : i need a MockPreparedStatement and a
> MockResultset as well. If i want to externalize the
> creation of my MockObjects from the TestCase perspective
> (ok thats perhaps arguable), i have no practical way to do
> it, since i will have to call verify() on both
> myMockPreparedStatement and myMockResultset as well. But
> since the creation of the MockObject was delegated, i lost
> the references to those objects (and also
> Verifier.verifyObject() doesnt verify myPreparedStatement :
> it just ensure that it has been used).
> > > There's also a crappy work-around : using AspectJ, we
> can these functionnality at the price of extending
> MockConnection, MockPreparedStatement and MockResultSet.
> thats not satisfactory tho. so the better way i think would
> be to modify MockObject class to make it composite. What do
> you think of this ?
> > >
> > > -- gd
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by: OSDN - Tired of that
> same old
> > > cell phone? Get a new here for FREE!
> > >
> https://www.inphonic.com/r.asp?r=3Dsourceforge1&refcode1=3Dvs339
> 0
> > >
> > > Mockobjects-java-users mailing list
> > > Moc...@li...
> > >
> https://lists.sourceforge.net/lists/listinfo/mockobjects-jav
> a-users
> > --
> > Dr. Nathaniel Pryce, Technical Director, B13media Ltd.
> > Studio 3a, 22-24 Highbury Grove, London N5 2EA, UK
> > http://www.b13media.com
> >
> >
> >
>=20
>=20
>=20
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r_________________________________________=
______
> Mockobjects-java-users mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-users
--=20
jeff martin
information technologist
mkodo limited

mobile: 44 (0) 78 5547 8331
phone: 44 (0) 20 2226 4545
email: je...@mk...

www.mkodo.com