Alex
Thank you for the comments on the article draft.
"However, it's also a bit
complex. Those anonymous classes, I always wanted to stay away from
them."
I agree as to complexity. Unfortunately, it is the syntax rather than the
logic of inner classes that creates the perception they are complex. Once
you use them a few times, it becomes fairly natural and I have not
experienced any compiler or JVM errors as a result.
"If you can do the same thing in a simpler way, then I like the simple
option"
I have not yet seen any other way to achieve this level of granularity in
unit testing. The next closest thing is actually mocking up an entire
interface or container in external classes. For method-by-method unit
testing, I do not think this is very efficient and my experience is that you
have to start writing convoluted testing logic to get particular mock
classes to work for all needed tests. I would love to see another approach
to getting this level of granularity in a simpler model without the need of
inner and anonymous classes.
"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?"
I would put aside HTML verification in this model, because I do not really
consider it unit testing. I did some attempts at HTML and output stream
verification and basically found myself rewriting the production class logic
in the testing class to retrieve the dynamic pieces of the HTML output. In
general, I think a single visual check and then regression testing (perhaps
by storing a checksum of the output) is a more efficient way as long as you
have a reporting and comparing mechanism that informs you of changes in the
output from run to run. This also assumes, of course, that you are using the
same test data from run to run. Pure speculation here as I've not fully
tested this form of testing myself.
As for a well designed mock object test class, I've yet to see a design
whose verify() method is adequate for more than a couple tests. In most
explanatory literature, what is shown is an "external" mock object
custom-designed to a
single test, so of course the mock object works because it is designed for
that test. However, when you have ten tests that use that mock object,
things start to fall apart fairly quickly or, if nothing else, the verify()
method of the mock class starts to get very complex. If you have counter
examples, please let me know.
Tom
