Thanks for the article preview!
It looks good, and I can see its utility. However, it's also a bit
complex. Those anonymous classes, I always wanted to stay away from
them.
If you can do the same thing in a simpler way, then I like the simple
option. If you require folks to write anonymous classes, they will stay
away.
However, HTML verification is also a complex subject, I understand that
the motivation is to have access to the mock-object internals from the
verify() method? Wouldn't a well-designed mock object test class allow
the same things?
References: Martin Fowler, "Refactoring".
Un saludo,
Alex.
Thomas Calivera wrote:
>
> Vincent
>
> "With MO, the problem is for test writer to have to
> implement a mock container (or some parts of it)."
>
> I disagree with the assumption that test writers have to write a mock
> container to do MO. I think we can accomplish fully functional unit testing
> with *patterns* rather than frameworks or mocked containers. To wit, I am in
> the midst of writing an article on mock object testing with patterns that
> extends some ideas found here and at the mock objects project on SF with a
> new twist. I am attaching an early draft here with pseudo-code, if you are
> interested. I am successfully using some of the patterns in a fairly complex
> project currently. (Feedback is welcome and Alex, if you are reading this,
> could this help with your current EJB work?)
>
> The short of the matter is that I do not think we need to create a mock
> container to do unit testing with servlets. Now, integration testing is
> another matter, and that is where Cactus' in-container testing really comes
> to the fore. Although it is my preference that unit testing be separate from
> integration testing both in code and management, I think there are some
> solutions in your vote proposal that use method name space or external
> configuration to identify the methodology of different tests (mock versus
> in-container) that still allows the use of these patterns if it is essential
> that Cactus manage everything to do with testing.
>
> "a good MO implementation would not return null or do
> nothing but rather would raise a runtime exception ... (like a
> NotImplementedException)."
>
> Very smart! I like it so much I added it to the draft patterns before
> attaching it here.
>
> "What you are saying in essence is "leave the choice open for the test
> writer
> instead of forcing him/her to use a given solution". This is fine but then
> what would happen when you run your test in IC mode. What would cactus do
> about the WebXmlQuery ? "
>
> Although this is probably moot at this point, WebXmlQuery or
> MockServletConfig would just serve as a utility to mock classes that need to
> get some information from web.xml. Or, thinking of it another way, perhaps
> there is no place for web.xml when testing with mock objects since web.xml
> is fundamentally a container crutch?
>
> Tom
>
> ------------------------------------------------------------------------
> Name: testingPatterns.txt
> testingPatterns.txt Type: Plain Text (text/plain)
> Encoding: quoted-printable
