Hi, In this case you may want to use Selenium/WebDriver tests. Or any kind of robot that will execute your test scenarios against a running web application.
In case you know/like JavaScript I'd recommend you: http://wicketinaction.com/2012/11/javascript-based-functional-testing/ We use such tests for testing several Wicket Examples applications: https://github.com/apache/wicket/tree/master/wicket-examples/src/main/webapp/js-test On Sun, Dec 1, 2013 at 5:09 PM, Martin Dietze <d...@fh-wedel.de> wrote: > 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: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
