Hi Paul, Not sure if I got you right but you might check out: https://bitbucket.org/kubek2k/springockito/wiki/Home
Best regards Andi 2013/6/12 Paul Bors <[email protected]>: > I like the simplicity of Mockito and got it working in my unit tests, but now > I find myself mocking more services than I wanted. > > Wicket Page Teste allows you to inject your mocks on top of the SpringBeans, > is that possible with Mockito? > http://WicketPageTest.sourceforge.net/ > > In other words I want to have my normal XML mapped beans context have some > beans be overridden only for some tests (talk about being lazy). > > ~ Thank you, > Paul Bors > > -----Original Message----- > From: heikki [mailto:[email protected]] > Sent: Tuesday, June 11, 2013 11:14 AM > To: [email protected] > Subject: Re: Unit testing a repeater or data table by mocking its data > > dear Paul, > > I've recently used Mockito and am quite happy with it. You can easily mock > any class and make it behave as you need. > > Best regards > Heikki Doeleman > > > On Tue, Jun 11, 2013 at 5:08 PM, Paul Bors <[email protected]> wrote: > >> Up to recently we got away with running our unit tests fully >> integrated with the back end db by performing live queries via our >> DAOs. >> >> Due to recent changes to our product schema we run into the inevitable >> high cost of having to spend too much time on maintain our mocked unit >> test data straight into the db. To cut down on that cost I would like >> to start mocking most of our DAOs that back-up the data tables in our >> product (gradually over time). >> >> >> >> Which brings me to my question, what's the recommended approach from >> Wicket's team (or users) on mocking the DAOs that are used by the data >> providers of your data tables? >> >> >> >> Our advantage is that we are using Spring and thus we could rely on >> spring-test, its ReflectionTestUtils but I also took a look at >> Mockito, EasyMock and such. >> >> I'm more curious as to what has been your experience in the past and >> what would you consider to be the best approach? >> >> >> >> ~ Thank you, >> >> Paul Bors >> >> >> >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
