Recent changes to feature-requests

provide an expectMultiple() type method?

Keith Quint — Thu, 15 Jan 2004 11:15:41 -0000

There are a number of times when we expect a method to
be called and we are not bothered what the arguments are.
In steps the .expect(object,C.ANY_ARGS) however, there are
also a number of occasions where we expect a method to be
called multiple times and we still dont care whats passed
nor do we actually know how many times its going to be
called. Ie when we mock the apache.commons.logger we
may not care what we log or how often. Is it possible to
create an expectMultiple(object,C.ANY_ARGS) type method?
You could, if you desired, count the number of calls and
verify this.

This is not necessarily a problem in that you could created a
MockLogger() class instead of using the dynamic mock of the
Log interface and just implemented each method with stubs.

Kind regards
Keith

Validation of Mock.expect*(..) arguments

Barry Kaplan — Fri, 22 Aug 2003 22:04:35 -0000

A very common error in test setup is to define
expectations for which there never will be match. For
example, given:

public interface Foo {
public void bar(Blob blob);
}
...
// 1. no method tweetle on interface
mockFoo.expect("tweetle", aBlob);
// 2. no bar method that takes two arguments
mockFoo.expect("bar", C.args(C.eq(aBlob), C.eq(aTweetle)));
// 3. no bar method that returns a Tweetle
mockFoo.expectAndReturn("bar", aBlob, aTweetle);
// 4. no bar method that takes a Tweetle argument
mockFoo.expect("bar", C.eq(aTweetle));

1, 2, 3 /could/ be done with the current design. It
just isnt' resulting strange test executions that
could have failed immediatly at setup time.

4 would require some method of "knowing" a constraint's
type. That is the type of its argument. Of course this
may not always be possible, but when it is could be
used to help validate the expectations.

---

Comment from Nat on this subject:

Request 4 is impossible for most constraints (because a
Constraint has no concept of "type") unless we extend
the Constraint interface with methods that to perform
early checks. However, I would rather keep the
Constraint interface as simple as possible to make it
trivially easy to write new Constraints. That approach
has helped make the
Constraint concept very easy for new users to
understand and use, and also kept the Constraint
interface very stable (it hasn't changed since first
introduced).

Add match() to new DynaMock API

Vincent Massol — Fri, 16 May 2003 07:22:31 -0000

Here's the use case for a new match():

I have in my code a call to queueConnection.close()
(for example). I use a Mock for QueueConnection. If I
*don't* define either an expect*() or a match*(), I get:

junit.framework.AssertionFailedError:
mockQueueConnection: Unexpected call: close()
Expected no methods
at com.mockobjects.dynamic.Mock.invoke
(Mock.java:95)
[...]

Which means to me that we have to define the
behaviour for any method called (and that there is no
default behaviour assumed). Fine with me. Then, I don't
want to set an expectation on close() because this
mock setup is part of a general setup that I want to
reuse across several tests and some tests do call close
(), some do not.

But there is no match() method.

Basically I'd like to simply tell DynaMock that I don't
care about this close() method. ATM, I've tricked it, by
using:

mockQueueConnection.matchAndReturn("close",
null);

But that seems like a hack (or even a DynaMock bug)
to me.

Thanks
-Vincent

Make Dynamic Objects work with any class

Chris Nokleberg — Thu, 08 May 2003 17:05:31 -0000

I didn't really want to subscribe to the dev list, and
you don't have any forums, so I hope you find my
message this way :-)

I'm a developer with cglib.sf.net. It uses bcel to
dynamically create classes at runtime, for a variety of
use cases. If you switched your dynamic Mock class to
use cglib instead of java.lang.reflect.Proxy, you could:

- be compatible with JDK 1.2
- mock almost any class (must have a non-private
constructor, and private or final methods cannot be mocked)
- perhaps realize a speed increase (creation of
object is slower, but method invocations are faster)

I'll probably be using mock objects more soon, so I
might do this anyway, but if you are interested let me
know, I can point you in the right direction.

chris at sixlegs dot com

MockHttpSession and MockHttpServletRequest

Mingfai — Thu, 16 Jan 2003 02:17:32 -0000

The MockHttpSession and MockHttpServletRequest
consists of many unimplemented method that throw
exception. This is make them not too useful. I would like
to request for:

1. make them as abstract and make the unimplemented
methods as abstract methods, so I can extend the
class conveniently. (instead of checking for the list of
unimplemented methods in the source one by one), or

2. best of all, implement them!

regards,
mingfai