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 approach. 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 :) Cheers, M'bert -- ----------- / 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: [email protected] For additional commands, e-mail: [email protected]
