You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Paul Bors <pa...@bors.ws> on 2013/06/11 17:08:59 UTC
Unit testing a repeater or data table by mocking its data
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
RE: Unit testing a repeater or data table by mocking its data
Posted by Paul Bors <pa...@bors.ws>.
Thanks I'll try that the next time I need to override a single bean.
For now I got my entire test suite working by mocking all the beans
necessary to initialize the webapp and authenticate the user.
Took longer but I like it since I am in full control :)
~ Thank you,
Paul Bors
-----Original Message-----
From: Andreas Kuhtz [mailto:andreas.kuhtz@gmail.com]
Sent: Friday, June 14, 2013 4:25 AM
To: users@wicket.apache.org
Subject: Re: Unit testing a repeater or data table by mocking its data
You can define a mock with the same bean id that will override the
original bean (e.g. in a applicationContext-test.xml). This is a
spring feature.
Then load the applicationContext-test.xml after the applicationContext.xml:
@ContextConfiguration(loader = SpringockitoContextLoader.class,
locations = {"classpath:applicationContext.xml",
"classpath:applicationContext-test.xml"})
I think it should work even without the special loader in
@ContextConfiguration and Remove the @ReplaceWithMock, at least it
worked for me in the past. This is described at top of
https://bitbucket.org/kubek2k/springockito/wiki/Home however the
configuration with the 2 locations is omitted (which is bad for
starters ...).
@ContextConfiguration(locations = {"classpath:applicationContext.xml",
"classpath:applicationContext-test.xml"})
I think you can see that the bean is overriden if you lower the log
level to debug for org.springframework (... out of my head, don't
remember which package exactly ...).
Hope this helps.
2013/6/13 Paul Bors <pa...@bors.ws>:
> Okay, so what's the easiest way to replace a single bean with a mock?
> I tried Springockito's @ReplaceWithMock w/o any luck.
>
> My webapp in testing is configured as follows:
> public class BaseConsoleTest extends SpringTest {
> ...
> ConsoleApplication testConsoleApplication = new
> ConsoleApplication() {
> @Override
> public ServletContext getServletContext() {
> ServletContext servletContext =
> super.getServletContext();
> XmlWebApplicationContext wctx = new
> XmlWebApplicationContext();
> wctx.setParent(getSpringApplicationContext());
> wctx.setConfigLocation("");
> wctx.setServletContext(servletContext);
> wctx.refresh();
>
>
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTE
> XT_ATTRIBUTE, wctx);
> return servletContext;
> }
> @Override
> protected void onDestroy() {
> super.onDestroy();
> if(tester != null) {
> tester.destroy();
> tester = null;
> }
> }
> @Override
> public Class<? extends Page> getHomePage() {
> Class<? extends Page> testHomePage =
> super.getHomePage();
> return (testHomePage == null) ? MyDummyPage.class
:
> testHomePage;
> }
> };
> ...
> }
>
> This class extended:
> @ContextConfiguration(loader = SpringockitoContextLoader.class, locations
=
> {"classpath:applicationContext.xml"})
> @TransactionConfiguration(defaultRollback = true)
> @Transactional
> public abstract class SpringTest extends
> AbstractTransactionalTestNGSpringContextTests {
> // Setup data sources
> }
>
> Simply enough I just want to mock and inject the new mock by replacing a
> single DAO defined in my applicationContext.xml.
>
> The test I've tried:
> @Test
> public class GroupingBaseTestPage extends BaseConsoleTest {
> ...
> @ReplaceWithMock
> @Autowired
> private DictionaryGroupingDao dictionaryGroupingDao;
> ...
> }
>
> Now each time I tried to define a mock for dictionaryGroupingDao the real
> bean is called instead:
>
>
when(dictionaryGroupingDao.countAvaialbleItems(Mockito.<DictionaryGroupingQu
> eryParams>any())
> ).thenReturn(
> getCount()
> );
>
> The above dictionaryGroupingDao.countAvaialbleItems() executes on the real
> bean as if @ReplaceWithMock never did its work.
>
> I've tried with regular Mockito via the @Mock and that mocks my bean but
it
> doesn't inject it into my Wicket's app :(
>
> Right now I gave up on Springockito and resorted to simply using Mockito
for
> the mocks I need with a ApplicationContextMock which is killing me as I
have
> quite a lot of mocks to implement just to get the user logged in to the
> application and start a single page :(
>
> I don't yet want to use Spring's ProxyFactoryBean in conjunction with
> HotSwappableTargetSource as it would make a mess of my
> applicationContext.xml.
>
> ~ Thank you,
> Paul Bors
>
> -----Original Message-----
> From: Andreas Kuhtz [mailto:andreas.kuhtz@gmail.com]
> Sent: Wednesday, June 12, 2013 11:26 AM
> To: users@wicket.apache.org
> Subject: Re: Unit testing a repeater or data table by mocking its data
>
> 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 <pa...@bors.ws>:
>> 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:tropicano@gmail.com]
>> Sent: Tuesday, June 11, 2013 11:14 AM
>> To: users@wicket.apache.org
>> 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 <pa...@bors.ws> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unit testing a repeater or data table by mocking its data
Posted by Andreas Kuhtz <an...@gmail.com>.
You can define a mock with the same bean id that will override the
original bean (e.g. in a applicationContext-test.xml). This is a
spring feature.
Then load the applicationContext-test.xml after the applicationContext.xml:
@ContextConfiguration(loader = SpringockitoContextLoader.class,
locations = {"classpath:applicationContext.xml",
"classpath:applicationContext-test.xml"})
I think it should work even without the special loader in
@ContextConfiguration and Remove the @ReplaceWithMock, at least it
worked for me in the past. This is described at top of
https://bitbucket.org/kubek2k/springockito/wiki/Home however the
configuration with the 2 locations is omitted (which is bad for
starters ...).
@ContextConfiguration(locations = {"classpath:applicationContext.xml",
"classpath:applicationContext-test.xml"})
I think you can see that the bean is overriden if you lower the log
level to debug for org.springframework (... out of my head, don't
remember which package exactly ...).
Hope this helps.
2013/6/13 Paul Bors <pa...@bors.ws>:
> Okay, so what's the easiest way to replace a single bean with a mock?
> I tried Springockito's @ReplaceWithMock w/o any luck.
>
> My webapp in testing is configured as follows:
> public class BaseConsoleTest extends SpringTest {
> ...
> ConsoleApplication testConsoleApplication = new
> ConsoleApplication() {
> @Override
> public ServletContext getServletContext() {
> ServletContext servletContext =
> super.getServletContext();
> XmlWebApplicationContext wctx = new
> XmlWebApplicationContext();
> wctx.setParent(getSpringApplicationContext());
> wctx.setConfigLocation("");
> wctx.setServletContext(servletContext);
> wctx.refresh();
>
> servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTE
> XT_ATTRIBUTE, wctx);
> return servletContext;
> }
> @Override
> protected void onDestroy() {
> super.onDestroy();
> if(tester != null) {
> tester.destroy();
> tester = null;
> }
> }
> @Override
> public Class<? extends Page> getHomePage() {
> Class<? extends Page> testHomePage =
> super.getHomePage();
> return (testHomePage == null) ? MyDummyPage.class :
> testHomePage;
> }
> };
> ...
> }
>
> This class extended:
> @ContextConfiguration(loader = SpringockitoContextLoader.class, locations =
> {"classpath:applicationContext.xml"})
> @TransactionConfiguration(defaultRollback = true)
> @Transactional
> public abstract class SpringTest extends
> AbstractTransactionalTestNGSpringContextTests {
> // Setup data sources
> }
>
> Simply enough I just want to mock and inject the new mock by replacing a
> single DAO defined in my applicationContext.xml.
>
> The test I've tried:
> @Test
> public class GroupingBaseTestPage extends BaseConsoleTest {
> ...
> @ReplaceWithMock
> @Autowired
> private DictionaryGroupingDao dictionaryGroupingDao;
> ...
> }
>
> Now each time I tried to define a mock for dictionaryGroupingDao the real
> bean is called instead:
>
> when(dictionaryGroupingDao.countAvaialbleItems(Mockito.<DictionaryGroupingQu
> eryParams>any())
> ).thenReturn(
> getCount()
> );
>
> The above dictionaryGroupingDao.countAvaialbleItems() executes on the real
> bean as if @ReplaceWithMock never did its work.
>
> I've tried with regular Mockito via the @Mock and that mocks my bean but it
> doesn't inject it into my Wicket's app :(
>
> Right now I gave up on Springockito and resorted to simply using Mockito for
> the mocks I need with a ApplicationContextMock which is killing me as I have
> quite a lot of mocks to implement just to get the user logged in to the
> application and start a single page :(
>
> I don't yet want to use Spring's ProxyFactoryBean in conjunction with
> HotSwappableTargetSource as it would make a mess of my
> applicationContext.xml.
>
> ~ Thank you,
> Paul Bors
>
> -----Original Message-----
> From: Andreas Kuhtz [mailto:andreas.kuhtz@gmail.com]
> Sent: Wednesday, June 12, 2013 11:26 AM
> To: users@wicket.apache.org
> Subject: Re: Unit testing a repeater or data table by mocking its data
>
> 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 <pa...@bors.ws>:
>> 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:tropicano@gmail.com]
>> Sent: Tuesday, June 11, 2013 11:14 AM
>> To: users@wicket.apache.org
>> 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 <pa...@bors.ws> 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: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Unit testing a repeater or data table by mocking its data
Posted by Paul Bors <pa...@bors.ws>.
Okay, so what's the easiest way to replace a single bean with a mock?
I tried Springockito's @ReplaceWithMock w/o any luck.
My webapp in testing is configured as follows:
public class BaseConsoleTest extends SpringTest {
...
ConsoleApplication testConsoleApplication = new
ConsoleApplication() {
@Override
public ServletContext getServletContext() {
ServletContext servletContext =
super.getServletContext();
XmlWebApplicationContext wctx = new
XmlWebApplicationContext();
wctx.setParent(getSpringApplicationContext());
wctx.setConfigLocation("");
wctx.setServletContext(servletContext);
wctx.refresh();
servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTE
XT_ATTRIBUTE, wctx);
return servletContext;
}
@Override
protected void onDestroy() {
super.onDestroy();
if(tester != null) {
tester.destroy();
tester = null;
}
}
@Override
public Class<? extends Page> getHomePage() {
Class<? extends Page> testHomePage =
super.getHomePage();
return (testHomePage == null) ? MyDummyPage.class :
testHomePage;
}
};
...
}
This class extended:
@ContextConfiguration(loader = SpringockitoContextLoader.class, locations =
{"classpath:applicationContext.xml"})
@TransactionConfiguration(defaultRollback = true)
@Transactional
public abstract class SpringTest extends
AbstractTransactionalTestNGSpringContextTests {
// Setup data sources
}
Simply enough I just want to mock and inject the new mock by replacing a
single DAO defined in my applicationContext.xml.
The test I've tried:
@Test
public class GroupingBaseTestPage extends BaseConsoleTest {
...
@ReplaceWithMock
@Autowired
private DictionaryGroupingDao dictionaryGroupingDao;
...
}
Now each time I tried to define a mock for dictionaryGroupingDao the real
bean is called instead:
when(dictionaryGroupingDao.countAvaialbleItems(Mockito.<DictionaryGroupingQu
eryParams>any())
).thenReturn(
getCount()
);
The above dictionaryGroupingDao.countAvaialbleItems() executes on the real
bean as if @ReplaceWithMock never did its work.
I've tried with regular Mockito via the @Mock and that mocks my bean but it
doesn't inject it into my Wicket's app :(
Right now I gave up on Springockito and resorted to simply using Mockito for
the mocks I need with a ApplicationContextMock which is killing me as I have
quite a lot of mocks to implement just to get the user logged in to the
application and start a single page :(
I don't yet want to use Spring's ProxyFactoryBean in conjunction with
HotSwappableTargetSource as it would make a mess of my
applicationContext.xml.
~ Thank you,
Paul Bors
-----Original Message-----
From: Andreas Kuhtz [mailto:andreas.kuhtz@gmail.com]
Sent: Wednesday, June 12, 2013 11:26 AM
To: users@wicket.apache.org
Subject: Re: Unit testing a repeater or data table by mocking its data
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 <pa...@bors.ws>:
> 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:tropicano@gmail.com]
> Sent: Tuesday, June 11, 2013 11:14 AM
> To: users@wicket.apache.org
> 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 <pa...@bors.ws> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unit testing a repeater or data table by mocking its data
Posted by Andreas Kuhtz <an...@gmail.com>.
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 <pa...@bors.ws>:
> 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:tropicano@gmail.com]
> Sent: Tuesday, June 11, 2013 11:14 AM
> To: users@wicket.apache.org
> 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 <pa...@bors.ws> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: Unit testing a repeater or data table by mocking its data
Posted by Paul Bors <pa...@bors.ws>.
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:tropicano@gmail.com]
Sent: Tuesday, June 11, 2013 11:14 AM
To: users@wicket.apache.org
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 <pa...@bors.ws> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Unit testing a repeater or data table by mocking its data
Posted by heikki <tr...@gmail.com>.
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 <pa...@bors.ws> 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
>
>
>
>
>
>