----- Original Message -----
From: "Thomas Calivera" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, July 26, 2001 8:09 PM
Subject: Re: Cactus Roadmap & V2 Propsal RFC
> Vincent
>
> "Now, if you're saying that you actually don't need to write any mock
> implementation at all and that it could be generated for you "
>
> For interfaces, such as the servlet API, that is what I am saying. In
fact,
> I am also saying that you can generate just the specific parts necessary
to
> a test at the scope of the individual test itself.
>
> "- it has to use JDK 1.3, which is a problem as JDK 1.3 is far from being
> used everywhere (maybe in 2 years time)"
>
> Fair enough.
>
> "generating a mock implementation on the fly works for simple cases
only...
> If you want to be convinced, look at my previous post when I was giving
the
> example on mocking HttpURLConnection."
>
> I counter that *external mock implementation classes or mock containers*
> either
> work for simple cases only *or* end up in writing essentially a full class
> or container.
> :) I took a look at the HttpURLConnection you referenced and I do not see
> why you
> cannot mock that "on the fly." If there are some additional outcomes in
the
> forms of exceptions or errors to which you expect the test subject to
> respond
> appropriately, then you just write additional tests for
> those exception or errors and implement a quick anonymous class that
> obliges. It actually encourages focused, finely grained unit tests.
>
I think I am just understanding what you are saying. I have several other
articles on the subject and it seems there are 2 possibilities for writing a
MO implementation :
1/ write it as a simple normal implementation, i.e. reproduce the behaviour
mentionned in the spec. I understand that it can become very difficult and
time-consuming if the spec is complex (although I don't believe it will be a
real problem for the Servlet API, I can certainly see it as a challenge for
APIs such as JDBC or EJBs). This option means that the method logic is put
in the mock method itself.
or
2/ do not write an implementation at all ! (that's JDK 1.3) or have a very
simple and generic implementation (JDK < 1.3) and delegate the logic of what
the mock method will do to your test case. This means something like :
---
MockHttpServletRequest mock = new MockHttpServletRequest();
mock.expectException(java.lang.IllegalStateException.class);
ServletToTest servlet = new SevletToTest();
try {
servlet.doSomething(mock);
} catch (IllegalStateException e) {
...
}
---
or
---
MockHttpServletRequest mock = new MockHttpServletRequest();
mock.expectValue("Value expected");
ServletToTest servlet = new SevletToTest();
String result = servlet.doSomething(mock);
assertEquals("Value expected", result);
---
I seem to like more and more option 2/ ! Which is what I believe you are
saying, right ?
> "BTW, have you looked at the EasyMock project "
>
> I took a look and it does have some merit. In reading the documentation,
> however, I see that you cannot easily test the actual parameters that are
> passed from the test subject to a method of the mock object (unless I
missed
> something), which is important for rigorous unit tests. Moreover, Alex
made
> a great point about complexity and my feeling is that if you are going to
> negotiate a bit of complexity, you are better off doing it by learning
about
> some of the actual features of the Java language rather than the
> complexities of yet another library, especially when the Java language
> itself provides all the tools (if not better tools) the library does. As I
> edit the testing patterns article I put together, I will show how the
> ability to access references in the outside class from the inner testing
> class makes the rigorous checking of method calls very easy and powerful.
>
Now that I think I understand better what you mean, I'll reread your article
and give you my feedback.
> "I would be very happy to have your vote on the several polls I have
sent."
>
> Ok, ok :). Thanks for the article draft feedback.
>
> Tom
Thanks
-Vincent
