Hi,
I just want to mention that I do not like much the current unit testing
approach.
This is not related to the fact that I have actually spent more time to
create unit tests than to create the actual components -- I see this as
an investment in the future.
My problem is more conceptual. If we separate the component behaviour
into a 'result' and an 'algorithm to achieve that result', I think that
the unit tests should perform an end-to-end testing and verify the
'result', rather than emulate the 'algorithm' that achieves that result.
Please note that EasyMock does the latter.
In the specific case of web development, I believe the unit tests should
verify the output of the components, rather than the methods the
components invoke (or cause the invocation of). Note that the approach
to unit testing of the previous version of Tapestry was doing precisely
that (it is still possible, but it is not the focus).
The reason for this thinking is that unit testing should provide an
alternative path to reaching the goal, rather than an emulation of the
existing path. Consider what happens when a modification in a component
is performed in order to make it more efficient (i.e. changing the
'algorithm'). First, with the EasyMock approach pretty much all unit
tests containing that component will need to be modified, even though
the result is the same. Second, because of the work involved, the
developer will soon start to simply modify the unit tests to make them
work rather than think about whether what he is doing makes sense. Any
faults in the new algorithm will not be caught as a result.
I think it is important for the unit tests to verify the algorithms
correctness by checking the results using a different method. Otherwise
a duplication of any faults is just too easy to happen.
Just a some of my thoughts....
-mb
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
