Menu
▾
▴
mockobjects-java-dev
|
From: chris c. <drc...@ya...> - 2003-06-27 23:21:39
|
Hi all,
there's a bug/limitation in the DynamicUtil.proxyToString method that I'd
like to fix. It can't handle proxies in collections or where the toString
is called indirectly because the proxy is a field in some other class. The
reason this is irritating is that the DynamicUtil.proxyToString method is
used in displaying constraints when call has not been matched. The result
of this limitation is that if you have an unexpected call and some other
call has proxies in the constraints indirectly then the failure message is
masked by an unexpected call to toString.
a code snippet might make this clearer:
...
Action proxyAction1 = (Action) mockAction1.proxy();
Action proxyAction2 = (Action) mockAction2.proxy();
Collection listOfActions = new TestVector(proxyAction1, proxyAction2);
mockConfigVersion.expectAndReturn("applyToSubConfigs",
C.eq(versionRepository, listOfActions), true);
...
The DynamicUtil.proxyToString will not be able to display the listOfActions
properly so any failed expectation on mockConfigVersion will be hidden by
an unexpected call to "toString" on mockAction1. Lots of time will then be
spent stepping
through the code to find which call went wrong. This has happened to me
often enough to be a nuisance.
The solution I propose is to not use the DynamicUtil to handle the toString
and instead make the default behaviour of a proxy toString call to be to
return the name of the mock. This would be overriden if an expectation was
set on the toString or you could use the reset method to clear it. The
reason I think it should be done this way is that I can't see how the
DynamicUtil can be made to handle all the possible ways that the toString
might be called on the proxy. Also I think it is unusual to need to set an
expectation on toString (I have never done it other than to get around this
bug) but less unusual to use proxies inside other objects which are used in
constraints. The way I had thought of implementing this behaviour is to add
a match of toString into the callableAddable of the Mock on construction.
Any thoughts?
Chris
|
|
From: Steve F. <st...@m3...> - 2003-06-28 00:39:30
|
Would you care to write some failing tests?
As per solutions, you might want to look at the branch for Nat's latest
version. Some of the names have changed.
S.
chris cottee wrote:
> Hi all,
> there's a bug/limitation in the DynamicUtil.proxyToString method
> that I'd like to fix. It can't handle proxies in collections or where
> the toString is called indirectly because the proxy is a field in some
> other class. The reason this is irritating is that the
> DynamicUtil.proxyToString method is used in displaying constraints when
> call has not been matched. The result of this limitation is that if you
> have an unexpected call and some other call has proxies in the
> constraints indirectly then the failure message is masked by an
> unexpected call to toString.
> a code snippet might make this clearer:
> ...
> Action proxyAction1 = (Action) mockAction1.proxy();
> Action proxyAction2 = (Action) mockAction2.proxy();
> Collection listOfActions = new TestVector(proxyAction1, proxyAction2);
>
> mockConfigVersion.expectAndReturn("applyToSubConfigs",
> C.eq(versionRepository, listOfActions), true);
> ...
>
> The DynamicUtil.proxyToString will not be able to display the
> listOfActions properly so any failed expectation on mockConfigVersion
> will be hidden by an unexpected call to "toString" on mockAction1. Lots
> of time will then be spent stepping
> through the code to find which call went wrong. This has happened to me
> often enough to be a nuisance.
>
> The solution I propose is to not use the DynamicUtil to handle the
> toString and instead make the default behaviour of a proxy toString call
> to be to return the name of the mock. This would be overriden if an
> expectation was set on the toString or you could use the reset method to
> clear it. The reason I think it should be done this way is that I can't
> see how the DynamicUtil can be made to handle all the possible ways that
> the toString might be called on the proxy. Also I think it is unusual to
> need to set an expectation on toString (I have never done it other than
> to get around this bug) but less unusual to use proxies inside other
> objects which are used in constraints. The way I had thought of
> implementing this behaviour is to add a match of toString into the
> callableAddable of the Mock on construction.
>
> Any thoughts?
> Chris
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> Mockobjects-java-dev mailing list
> Moc...@li...
> https://lists.sourceforge.net/lists/listinfo/mockobjects-java-dev
|
|
From: Nat P. <nat...@b1...> - 2003-06-28 19:23:07
|
From: "Steve Freeman" <st...@m3...>
> As per solutions, you might want to look at the branch for Nat's latest
> version. Some of the names have changed.
I think the proposed solution is very neat, and could probably also be used
to move the checks for and processing of "magic" calls from the Mock class
into Callable objects.
However, how would it work with the OrderedMock class?
Cheers,
Nat.
|
|
From: chris c. <drc...@ya...> - 2003-06-30 08:03:33
|
On Sat, 28 Jun 2003 20:19:36 +0100, Nat Pryce <nat...@b1...> wrote: > From: "Steve Freeman" <st...@m3...> >> As per solutions, you might want to look at the branch for Nat's latest >> version. Some of the names have changed. > > I think the proposed solution is very neat, and could probably also be > used > to move the checks for and processing of "magic" calls from the Mock > class > into Callable objects. > > However, how would it work with the OrderedMock class? > > Cheers, > Nat. > > > I raised the question because I wondered what people thought about changing the contract of a proxy: that it would always respond to toString unless you explicitly told it not to. It had crossed my mind that this might cause trouble with OrderedMock but I think that handling the call to toString by adding a match in the constructor is an implementation detail really, very nice if it can be made to work but if we have to do something clunky then so be it. I'd want to think about what matching in an OrderedMock should mean though: should you have to match in the correct order? My instinct is no, matching should be allowed in any order.Any thoughts on that? Anyway given this broadly positive response (-no-one has said it's a *very* stupid idea yet) I shall knock something up on the train to work, in particular tests of Mock and OrderedMock. Cheers, Chris |
|
From: Nat P. <nat...@b1...> - 2003-07-02 15:13:04
|
From: "Nat Pryce" <nat...@b1...>
> I think the proposed solution is very neat, and could probably also be
used
> to move the checks for and processing of "magic" calls from the Mock class
> into Callable objects.
>
> However, how would it work with the OrderedMock class?
Thinking about this, perhaps the whole idea of an OrderedMock is wrong. It
seems that there are no cases where *all* method calls will happen in one
order. Testing explicitly ordered calls is pretty rare, rare enough that
having to write an extra line of code to create a CallSequence to specify
the expected sequence of calls is not really a big problem.
E.g. instead of:
OrderedMock listener = new OrderedMock(EventListener.class);
listener.expectVoid( "firstEvent", C.eq(firstEvent) );
listener.expectVoid( "secondEvent", C.eq(secondEvent) );
listener.expectVoid( "thirdEvent", C.eq(thirdEvent) );
A test would look like:
Mock listener = new Mock(EventListener.class);
CallCollectionBuilder eventSequence = listener.newSequence();
eventSequence.expectVoid( "firstEvent", C.eq(firstEvent) );
eventSequence.expectVoid( "secondEvent", C.eq(secondEvent) );
eventSequence.expectVoid( "thirdEvent", C.eq(thirdEvent) );
I can live with that. I even think that it makes the test more readable.
Regards,
Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661
|
|
From: Steve F. <st...@m3...> - 2003-07-02 22:14:00
|
We argued this one out and thought that in most case people either care
about the order or they don't. I'm not so keen on the newSequence()
because it doesn't make clear what happens to expectations applied to
the originating Mock. At least the OrderedMock has only one visible
behaviour.
We also considered adding something like:
listener.expectVoid( "first", C.before("second") );
S.
Nat Pryce wrote:
> Thinking about this, perhaps the whole idea of an OrderedMock is wrong. It
> seems that there are no cases where *all* method calls will happen in one
> order. Testing explicitly ordered calls is pretty rare, rare enough that
> having to write an extra line of code to create a CallSequence to specify
> the expected sequence of calls is not really a big problem.
>
> E.g. instead of:
>
> OrderedMock listener = new OrderedMock(EventListener.class);
> listener.expectVoid( "firstEvent", C.eq(firstEvent) );
> listener.expectVoid( "secondEvent", C.eq(secondEvent) );
> listener.expectVoid( "thirdEvent", C.eq(thirdEvent) );
>
> A test would look like:
>
> Mock listener = new Mock(EventListener.class);
> CallCollectionBuilder eventSequence = listener.newSequence();
> eventSequence.expectVoid( "firstEvent", C.eq(firstEvent) );
> eventSequence.expectVoid( "secondEvent", C.eq(secondEvent) );
> eventSequence.expectVoid( "thirdEvent", C.eq(thirdEvent) );
>
> I can live with that. I even think that it makes the test more readable.
>
> Regards,
> Nat.
> _______________________
> Dr. Nathaniel Pryce
> B13media Ltd.
> http://www.b13media.com
> +44 (0)7712 526 661
>
|
|
From: Nat P. <nat...@b1...> - 2003-07-02 22:56:59
|
From: "Steve Freeman" <st...@m3...>
> We argued this one out and thought that in most case people either care
> about the order or they don't.
It seems that there are always some methods that can occur out of order
(toString, etc.).
> I'm not so keen on the newSequence()
> because it doesn't make clear what happens to expectations applied to
> the originating Mock. At least the OrderedMock has only one visible
> behaviour.
Could this be fixed by a better name?
> We also considered adding something like:
> listener.expectVoid( "first", C.before("second") );
This gets tricky because you need to unambiguously identify the first and
second methods, and that gets difficult with the flexible way that methods
are matched using decorators. I find that putting callable objects into
sequences makes this explicit and is not very verbose.
Cheers,
Nat.
_______________________
Dr. Nathaniel Pryce
B13media Ltd.
http://www.b13media.com
+44 (0)7712 526 661
|
|
From: Steve F. <st...@m3...> - 2003-07-03 07:47:29
|
Nat Pryce wrote:
> From: "Steve Freeman" <st...@m3...>
>>We argued this one out and thought that in most case people either care
>>about the order or they don't.
> It seems that there are always some methods that can occur out of order
> (toString, etc.).
if they matter, then put them in the expectations (this is another
motivation for restructuring the special cases).
>>I'm not so keen on the newSequence()
>>because it doesn't make clear what happens to expectations applied to
>>the originating Mock. At least the OrderedMock has only one visible
>>behaviour.
> Could this be fixed by a better name?
not sure. it's more about 2 interfaces to the same behaviour.
>>We also considered adding something like:
>> listener.expectVoid( "first", C.before("second") );
> This gets tricky because you need to unambiguously identify the first and
> second methods, and that gets difficult with the flexible way that methods
> are matched using decorators. I find that putting callable objects into
> sequences makes this explicit and is not very verbose.
I suspect that simple name matching would work in practice. We also
talked about adding a before() method to the callable objects, which
would be unambiguous, but I couldn't be bothered to type in the example...
S.
--
"A LISP programmer knows the value of everything but the cost of nothing.
A C programmer knows the cost of everything but the value of nothing."
(Todd Proebsting)
|
|
From: Nat P. <nat...@b1...> - 2003-07-03 10:16:04
|
> > From: "Steve Freeman" <st...@m3...>
> >>I'm not so keen on the newSequence()
> >>because it doesn't make clear what happens to expectations applied to
> >>the originating Mock. At least the OrderedMock has only one visible
> >>behaviour.
> > Could this be fixed by a better name?
>
> not sure. it's more about 2 interfaces to the same behaviour.
Not if we get rid of the OrderedMock class as I am suggesting. I think this
will just make things a lot simpler. All Mocks are unordered. If you want
to set up an expectation on the order of certain calls, create a
CallSequence and add it to the mock, or use the newSequence sugar method.
That would also disallow confusing code such as:
private Mock mock; // This looks like it is declaring an unordered mock
...
pubic void setUp() {
mock = new OrderedMock( Interface.class ); // No it is actually an
ordered mock.
}
Cheers,
Nat.
|
|
From: chris c. <drc...@ya...> - 2003-06-30 08:02:45
|
Hi Steve,
here is the failing test of the DynamicUtil
in DynamicUtilTest
public void testProxyToString() throws Exception {
Mock mockDummyInterface = new Mock(DummyInterface.class, "an example");
DummyInterface proxyDummyInterface = (DummyInterface)
mockDummyInterface.proxy();
assertEquals("should get correct string", "an example",
DynamicUtil.proxyToString(proxyDummyInterface));
assertEquals("should get correct string for array", "[<an example>]",
DynamicUtil.proxyToString(new DummyInterface[] { proxyDummyInterface }));
List list = new ArrayList();
list.add(proxyDummyInterface);
assertEquals("should get correct string for list", "[an example]",
DynamicUtil.proxyToString(list));
class MyClass {
DummyInterface aField;
MyClass(DummyInterface aDummy) {
aField = aDummy;
}
public String toString() {
return "myClass contains:" + aField;
}
}
MyClass myClass = new MyClass(proxyDummyInterface);
assertEquals("should get string back from contained field", "myClass
contains:", DynamicUtil.proxyToString(myClass));
}
The first two asserts pass, the second two do not.
The other thing I would like to do is refactor the MockTest. I want to do
this because I tried out my one line change to Mock and it made every
single test fail. In trying to fix them I noticed that there is a lot of
duplication in the test and that some small changes to the CallFactory
interface would make the test a great deal simpler. For instance replacing
this method in Mock
public void expect(String methodName, ConstraintMatcher args) {
calls.addExpect(callFactory.createCallExpectation(callFactory.createCallSignature(methodName,
args, callFactory.createVoidStub())));
}
with something like this:
public void expect(String methodName, ConstraintMatcher args) {
calls.addExpect(callFactory.createCallExpectation(methodName, args));
}
and having changed the DefaultCallFactory to handle it would make it a lot
simpler to setup the expectations in the MockTest.
Alternatively I would suggest not using mocks to test Mock, I don't think
you need to. I think plain old fashioned exo-testing would cut it. This
would have the advantage of providing examples of usage and decoupling the
test from implementation, making it simpler to integrate with Nat's
changes.
Chris
|
|
From: Tim M. <tim...@po...> - 2003-06-30 22:53:07
|
> Alternatively I would suggest not using mocks to test Mock, I don't think > you need to. I think plain old fashioned exo-testing would cut it. This > would have the advantage of providing examples of usage and > decoupling the > test from implementation, making it simpler to integrate with Nat's I can comment that Nat and I tried that when we redid the current version test first - and the tests we were writing were very hard and not driving our design. We took the stance that we would use the old mock implementations to help, and this gave us a huge productivity boost (we decided not to use dynamics to test dynamics as that is a brain bender) - honest. We also found that using mock maker was a big time saver too (hand coding some of our interface changes was just too painful as well). Tim --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003 |
|
From: Nat P. <nat...@b1...> - 2003-07-01 08:24:01
|
From: "Tim Mackinnon" <tim...@po...>
> > Alternatively I would suggest not using mocks to test Mock, I don't
think
> > you need to. I think plain old fashioned exo-testing would cut it.
>
> I can comment that Nat and I tried that when we redid the current version
> test first - and the tests we were writing were very hard and not driving
> our design.
One problem we found with exo-testing is that it is suffers from
combinatorial explosion. The number of combinations of all possible
decorators and stubs is HUGE! For example, there are three types of stubs
in v0.09 (and I've added another), decorators to match method name,
arguments and check an expectated call, and the argument check can take
different numbers and types of constraint.
The new dynamic mock is designed in terms of collaborating, pluggable
objects. It's situations like this that mocks are perfect for because
exo-testing alone becomes very difficult. Unfortunately, it does lead to
mocks-testing-mocks headaches. Hopefully the documentation on the
mockobjects Wiki and the examples in the source distribution will be
helpful. Both need further work.
> We also found that using mock maker was a big time saver too (hand
> coding some of our interface changes was just too painful as well).
Again, dynamic mocks would help here, but using the dynamock library to test
itself is just too meta, even for my deranged tastes!
Cheers,
Nat.
|
|
From: chris c. <drc...@ya...> - 2003-07-01 22:45:48
|
I think there need to be some functional tests for Mock as well as the
mocked unit tests. Functional tests
are (in this case) better at expressing the intent of the code since they
are effectively examples of usage.
For instance what is the intended behaviour of the Mock if you setup a
match and then call it more than once? How about for OrderedMock?
I have to look at the tests for CallSequence and CallBag (in the 0.09
release) to figure this out which means that I have to
read the implementation to tell that Mock uses these things and I can't
tell from the tests what the intent is, it is easier to read the code. I
chose this example because the test is easy if you have setup a mock and
proxy
public void testMatchAndReturn() throws Throwable {
mock.matchAndReturn(METHOD_NOARGANDRETURN_NAME,
METHOD_NOARGANDRETURN_RESULT);
mock.verify();
for (int i = 0; i < 4; i++) {
assertEquals("should get expected result every time:" + i,
METHOD_NOARGANDRETURN_RESULT, proxy.noArgMethod());
}
mock.verify();
}
And it passes on Mock and fails on OrderedMock in both 0.09 versions and
Nat's branch. Now I don't know if OrderedMock
is supposed to treat matches differently to Mock or not and I really have
no way of telling. My feeling is that this is a
bug and that the only difference between Mock and OrderedMock should be the
way they handle the order of expected calls, in all other ways the
behaviour should be identical.
Is this right?
Chris.
|
|
From: Steve F. <st...@m3...> - 2003-07-01 22:58:11
|
chris cottee wrote: > I think there need to be some functional tests for Mock as well as the > mocked unit tests. Functional tests > are (in this case) better at expressing the intent of the code since > they are effectively examples of usage. Agreed. We've talked about writing some fit tests that would apply to both the java and C# versions. I'm beginning to find the current unit tests problematic too. I've been trying to add Chris's idea of just adding some default matches for methods like toString() and it's a right pain (and shouldn't necessarily be visible in the tests). Chris are you implementing all this in 0.09. If so, I'll stop. Also, I suggest you break up your proposed additional unit tests into 4 specific tests, rather than one big one. Steve |
|
From: Tim M. <tim...@po...> - 2003-07-01 23:35:52
|
Just as small comment, I would say the unit tests for dynamock haven't been through the ringer with different people so they probably need a bit of refactoring (not that this is an excuse). That said - what Chris is trying to do shouldn't be too hard if he paired with either nat or myself (you are trying to do this without a knowledge spread which is understandably difficult especially as dynamock was written in essentially two intense days by only two people). I will say we made some quite radical changes during the two days, and a bit afterwards and the tests weren't too hard to modify. So Yes - remembering how the old mocks work is crucial to reading the tests - we probably should back port the old mocks to the new format (but no-one has the time). I will restate that at the time, initially we didn't do mock style tests for dynamock and they really stalled our development (I distinctly remember this). You will also probably need MockMaker if you are playing around with the interfaces so you can easily regenerate the old mocks (doing it by hand is very time consuming). Functional testing is not really the answer (definitely its not a replacement for unit tests, i see too many people write fucntional tests, or very high level unit tests and then they feel they have the justification to hack for several hours getting their "test first test" to run. Its bad news!). There is a simple functional test for dynamock, its in the examples package, called SimpleServletTest - it was used as our way of expressing features we wanted to work, we then dropped down to unit test to get those features to work. It does have the downside that its servlet based, but it was the quickest example I could think of to show nat all of the types of interactions we had to deal with (and it drove the matchAndReturn syntax). Tim > -----Original Message----- > From: moc...@li... > [mailto:moc...@li...]On Behalf Of > Steve Freeman > Sent: 01 July 2003 23:58 > To: moc...@li... > Subject: Re: [MO-java-dev] DynaMock proxy toString issue > > > chris cottee wrote: > > I think there need to be some functional tests for Mock as well as the > > mocked unit tests. Functional tests > > are (in this case) better at expressing the intent of the code since > > they are effectively examples of usage. > > Agreed. We've talked about writing some fit tests that would apply to > both the java and C# versions. > > I'm beginning to find the current unit tests problematic too. I've been > trying to add Chris's idea of just adding some default matches for > methods like toString() and it's a right pain (and shouldn't necessarily > be visible in the tests). > > Chris are you implementing all this in 0.09. If so, I'll stop. Also, I > suggest you break up your proposed additional unit tests into 4 specific > tests, rather than one big one. > > Steve > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > 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.490 / Virus Database: 289 - Release Date: 16/06/2003 > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003 |
|
From: Tim M. <tim...@po...> - 2003-07-02 00:45:35
|
Not sure why the tests would be pain, isn't just a case of adding the two
following tests to mock?
public void testProxyToStringWithNoToStringExpectation() throws Exception {
mockCallableAddable.addExpectedHasCall("toString", METHOD_NOARG_ARGS);
mockCallableAddable.setupHasCall(false);
assertEquals("Should get mock name", MOCK_NAME, mock.proxy().toString());
mock.verify();
}
public void testProxyToStringWithToStringExpectation() throws Exception {
final String result = "configured result";
mockCallableAddable.addExpectedHasCall("toString", METHOD_NOARG_ARGS);
mockCallableAddable.setupHasCall(true);
mockCallableAddable.setupCall(result);
assertEquals("Should get mock name", MOCK_NAME, mock.proxy().toString());
mock.verify();
}
Thus - the mockCallableAddable (and I will admit its badly named -the name
ideas was you can send calls to it but also add expectations and matches) -
would expect to be asked if it has a "toString" call (i.e. a call to a new
method called HasCall on CallableAddable), we configure the mock either true
or false, in the true case you also have to setup a result that you assert
should be true.
Its not a big deal.
There is a smell, in some of the other tests because the CallFactory is a
bit over-used, it generates several types of stubs decorating each other (so
you have to set each of them up). I would say that this should be better
encapsulated so you just set one expectation on the mockCallFactory - the
tests would simplify and your code would be better.
Its simply the tests reflecting a poor design decision made at 4:30pm on day
one. Actually it was a good decision then, becuase it meant we moved on - we
have not been good at refactoring the code - but this was a spare time
coding excercise.
Tim
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Steve Freeman
> Sent: 01 July 2003 23:58
> To: moc...@li...
> Subject: Re: [MO-java-dev] DynaMock proxy toString issue
>
>
> chris cottee wrote:
> > I think there need to be some functional tests for Mock as well as the
> > mocked unit tests. Functional tests
> > are (in this case) better at expressing the intent of the code since
> > they are effectively examples of usage.
>
> Agreed. We've talked about writing some fit tests that would apply to
> both the java and C# versions.
>
> I'm beginning to find the current unit tests problematic too. I've been
> trying to add Chris's idea of just adding some default matches for
> methods like toString() and it's a right pain (and shouldn't necessarily
> be visible in the tests).
>
> Chris are you implementing all this in 0.09. If so, I'll stop. Also, I
> suggest you break up your proposed additional unit tests into 4 specific
> tests, rather than one big one.
>
> Steve
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> 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.490 / Virus Database: 289 - Release Date: 16/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
|
|
From: Steve F. <st...@m3...> - 2003-07-02 03:21:31
|
Tim Mackinnon wrote:
> Not sure why the tests would be pain, isn't just a case of adding the two
> following tests to mock?
>
> public void testProxyToStringWithNoToStringExpectation() throws Exception {
> mockCallableAddable.addExpectedHasCall("toString", METHOD_NOARG_ARGS);
> mockCallableAddable.setupHasCall(false);
>
> assertEquals("Should get mock name", MOCK_NAME, mock.proxy().toString());
> mock.verify();
> }
no. If the methods are added as defaults on Mock, during construction,
you have to fix the other tests so that calls to
MockCallFactory.createReturnStub() don't fail because it's short of a
return value. Which suggests that the callFactory is overspecified.
> There is a smell, in some of the other tests because the CallFactory is a
> bit over-used, it generates several types of stubs decorating each other (so
> you have to set each of them up). I would say that this should be better
> encapsulated so you just set one expectation on the mockCallFactory - the
> tests would simplify and your code would be better.
Exactly.
S.
|
|
From: Tim M. <tim...@po...> - 2003-07-02 06:30:28
|
These tests would work exactly as specified - I think the way you are trying
to solve the problem is wrong (e.g. you have misunderstood the metaphor that
all the other tests are based on).
Don't add the methods as defaults on construction (I think this would break
most objects in any design) - you just need to check if the method is
toString, and if an expectation/match has been set on the mock for it.
It is literally changing the following method in mock:
private boolean isMockNameGetter(Method method, Object[] args) {
return (method.getName().equals("toString")) && (args == null);
// to also check for expectation you need something like
// && !calls.hasCall("toString",args);
}
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> Steve Freeman
> Sent: 02 July 2003 04:08
> To: moc...@li...
> Subject: Re: [MO-java-dev] DynaMock proxy toString issue
>
>
> Tim Mackinnon wrote:
> > Not sure why the tests would be pain, isn't just a case of
> adding the two
> > following tests to mock?
> >
> > public void testProxyToStringWithNoToStringExpectation()
> throws Exception {
> > mockCallableAddable.addExpectedHasCall("toString",
> METHOD_NOARG_ARGS);
> > mockCallableAddable.setupHasCall(false);
> >
> > assertEquals("Should get mock name", MOCK_NAME,
> mock.proxy().toString());
> > mock.verify();
> > }
>
> no. If the methods are added as defaults on Mock, during construction,
> you have to fix the other tests so that calls to
> MockCallFactory.createReturnStub() don't fail because it's short of a
> return value. Which suggests that the callFactory is overspecified.
>
> > There is a smell, in some of the other tests because the
> CallFactory is a
> > bit over-used, it generates several types of stubs decorating
> each other (so
> > you have to set each of them up). I would say that this should be better
> > encapsulated so you just set one expectation on the
> mockCallFactory - the
> > tests would simplify and your code would be better.
>
> Exactly.
>
> S.
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> 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.490 / Virus Database: 289 - Release Date: 16/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
|
|
From: Tim M. <tim...@po...> - 2003-07-02 00:11:20
|
The functional test is in examples (the package name probably bad). This was
the functional test we used to drive the thing. It may be slightly
incomplete but it shows most of the usage.
You are correct that its missing an example of using matchAndReturn twice -
it does show expectAndReturn twice however.
> -----Original Message-----
> From: moc...@li...
> [mailto:moc...@li...]On Behalf Of
> chris cottee
> Sent: 01 July 2003 23:46
> To: Tim Mackinnon; moc...@li...; Nat Pryce
> Subject: Re: [MO-java-dev] DynaMock proxy toString issue
>
>
> I think there need to be some functional tests for Mock as well as the
> mocked unit tests. Functional tests
> are (in this case) better at expressing the intent of the code since they
> are effectively examples of usage.
>
> For instance what is the intended behaviour of the Mock if you setup a
> match and then call it more than once? How about for OrderedMock?
>
> I have to look at the tests for CallSequence and CallBag (in the 0.09
> release) to figure this out which means that I have to
> read the implementation to tell that Mock uses these things and I can't
> tell from the tests what the intent is, it is easier to read the code. I
> chose this example because the test is easy if you have setup a mock and
> proxy
>
> public void testMatchAndReturn() throws Throwable {
> mock.matchAndReturn(METHOD_NOARGANDRETURN_NAME,
> METHOD_NOARGANDRETURN_RESULT);
> mock.verify();
> for (int i = 0; i < 4; i++) {
> assertEquals("should get expected result every time:" + i,
> METHOD_NOARGANDRETURN_RESULT, proxy.noArgMethod());
> }
>
> mock.verify();
> }
> And it passes on Mock and fails on OrderedMock in both 0.09 versions and
> Nat's branch. Now I don't know if OrderedMock
> is supposed to treat matches differently to Mock or not and I really have
> no way of telling. My feeling is that this is a
> bug and that the only difference between Mock and OrderedMock
> should be the
> way they handle the order of expected calls, in all other ways the
> behaviour should be identical.
>
> Is this right?
> Chris.
>
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
> _______________________________________________
> 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.490 / Virus Database: 289 - Release Date: 16/06/2003
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.490 / Virus Database: 289 - Release Date: 16/06/2003
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X