On Sat, November 30, 2013, Martin Grigorov wrote:

> Usually when running (WicketTester) tests people provide mock
> implementations of the external services like MQ, DB, ...
> It is much easier to return some mock data, either good data or broken, to
> your application and verify that it behaves correctly in both situations.

I really don't like mocking services and DAOs at all, because in
complex application this sooner or later leads you to testing
against your particular implementation rather than your code's
contract. In particular when mocking frameworks are used, this
very easily leads to write-only test code. I've seen this on too
many occasions and no longer believe that this is a wise

Also one needs to consider that many applications are pretty
much data-driven (e.g. my system uses a document-based data
model with nearly 100 different object variants), and loading and
interpreting both schema and data is a crucial piece of the
application and needs thorough testing, and you really want to
do this on the real thing rather than on mocked services. 

If I were to start such a project today I'd rely on IOC
frameworks like Spring or Guice trying to keep my modules' 
dependencies under control, so that I can write test data
generators for all the scenarios I need to test. However in a
legacy project this is not always an option because a
pre-spring/guice architecture may lead to practically every
module technically depending on the complete business logic, 
so that one would have to pretty much mock it all which will
make the test code even more unmaintainable. In my case I'm fine
using anonymized production data based on which I can write
tests not relying on particular objects in the database but on
classes of data that will be there instead.

Now that's *why* I chose that approach. Still, if anybody has
any experience with this kind of thing, I'd be happy to benefit
from it :)



----------- / http://herbert.the-little-red-haired-girl.org / -------------
Hlade's Law: If you have a difficult task, give it to a lazy person;
           they will find an easier way to do it. 

To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to