Testing DataView Redux
Hi All, I originally posted this message yesterday as a response to the post called Testing DataView (see http://www.nabble.com/Testing-DataView-td21863271.html). For some reason, my response didn't show up in the list as one of the most recent comments. So I am posting it again as a new message so please excuse the redundancy. I am also going through the unit testing learning curve. Unfortunately, I didn't really understand the discussion about testing the DataView component. I just implemented my first DataView code, which is more or less a copy of the Wicket Sorting DataView example (see http://www.wicket-library.com/wicket-examples/repeater/?wicket:bookmarkablePage=:org.apache.wicket.examples.repeater.SortingPage) Any further pointers on testing DataViews would be most welcome (BTW, I have been using EasyMock for integration testing). Thanks guys! Steve
Re: Testing DataView
Hi All, I'm also going through the unit testing learning curve. Unfortunately, I didn't really understand the discussion about testing the DataView component. I just implemented my first DataView code, which is more or less a copy of the Wicket http://www.wicket-library.com/wicket-examples/repeater/;jsessionid=876AF7E1C1F6C0B7463DF0D4B1D4627A?wicket:bookmarkablePage=sources:org.apache.wicket.examples.source.SourcesPageSourcesPage_class=org.apache.wicket.examples.repeater.SortingPage Sorting DataView example. Any further pointers on testing DataViews would be most welcome (BTW, I have been using EasyMock for integration testing). Thanks guys! -- View this message in context: http://www.nabble.com/Testing-DataView-tp21863271p25517641.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
I was able to get my tests to work. Timo's advice of using HttpSessionStore, led me to realize that WicketTester and, more importantly, DummyApplication (which I was not using since I'm not using JUnit) seem to take care of the mocking serialization problems. I decided to use those built-in classes for now, until I can create a custom ones specifically for use with Specs (the testing framework i'm using). I'm not seeing the 2.7.3 serialization issue as of now, but it's good to now for future problems. By the way, I think the hardest part about Unit testing and TDD specifically is that, if you don't know your frameworks really well (I'm new to Wicket), then you constantly run into brick walls. It's kind of a chicken before the egg problem.
Re: Testing DataView
On Sun, 08 Feb 2009, Erick Fleming wrote: I know Wicket likes everything to be serializable so does this mean that mocking frameworks are not compatible by default? By the way, I've heard from my Scala-using colleagues that some Scala versions have had trouble in serialising some inner classes. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
Hi, By the way, I've heard from my Scala-using colleagues that some Scala versions have had trouble in serialising some inner classes. that should work with Scala 2.7.2 - in the current version it's broken if inheriting serializable from Java classes. It's already fixed and should be ok with the next version again. Best regards, --- Jan. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
On Thu, 05 Feb 2009, Erick Fleming wrote:
I'm new to unit testing and just trying to get my feet wet. The actual code
under test would be a panel that should display some data. I guess I don't
really care to test wicket's dataview but whether or not my panel is
actually displaying the data. Should I mock the IDataProvider and verify
that certain methods are called?
Yes, and that their data is fed correctly to the items.
I'm using Scala, but this is a rough translation of the panel.
Thanks, we all should learn Scala anyway so feel free to
post in it ;)
public AccountListPanel(String id, IDataProvider provider) {
Pass in a mock IDataProvider there, and then see that the
accounts that the mock returns get listed on the page.
for (Account account : accountsSuppliedByMockDataProvider) {
assertEquals(account, findItemOf(account).getModelObject());
assertEquals(account.getName(),
findNameLabelOf(account).getModelObjectAsString());
}
Or something like that.
If your repeater initialises lazily, you sometimes have to
call .renderComponent() on it on the test so that its
children get created. But if it already gets its data on
when it's first constructed and started by WicketTester, it
should be rendered and the Items should be there.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
Timo, Thanks alot for the feedback.
I'm getting close, but am running into a serialization problem with the
mocked IDataProvider (JMock and Mockito).
2 [class=org.apache.wicket.util.tester.DummyPanelPage, path=2]
private java.lang.Object org.apache.wicket.MarkupContainer.children
[class=org.rockcoder.scheduler.accounts.AccountListPanel, path=2:panel]
private java.lang.Object org.apache.wicket.MarkupContainer.children
[class=org.rockcoder.scheduler.accounts.AccountListPanel$$anon$1,
path=2:panel:list]
private final org.apache.wicket.markup.repeater.data.IDataProvider
org.apache.wicket.markup.repeater.data.DataViewBase.dataProvider
[class=$Proxy5]
protected java.lang.reflect.InvocationHandler
java.lang.reflect.Proxy.h [class=org.jmock.lib.JavaReflectionImposteriser$1]
- field that is not serializable
I know Wicket likes everything to be serializable so does this mean that
mocking frameworks are not compatible by default?
object tester extends BaseWicketTester(new MyApplication {
override val mode = test
})
object AccountsSpecification extends Specification with JMocker {
given an account provider, the accounts list panel should {
display a list of all accounts in {
accountProvider = mock[IDataProvider[Account]]
expect {
one(accountProvider).iterator(anyInt, anyInt)
one(accountProvider).size
one(accountProvider).detach
}
tester.startPanel(new TestPanelSource {
override def getTestPanel(id: String): Panel = new
AccountListPanel(id, accountProvider)
})
}
}
}
class AccountListPanel(id: String, accounts: IDataProvider[Account]) extends
Panel(id) {
add(new DataView[Account](list, accounts) {
override def populateItem(item: Item[Account]) {
val account = item.getModelObject
item.add(new Label(id, account.id.toString))
item.add(new Label(name, account.name))
}
})
}
On Sun, Feb 8, 2009 at 3:54 AM, Timo Rantalaiho timo.rantala...@ri.fiwrote:
On Thu, 05 Feb 2009, Erick Fleming wrote:
I'm new to unit testing and just trying to get my feet wet. The actual
code
under test would be a panel that should display some data. I guess I
don't
really care to test wicket's dataview but whether or not my panel is
actually displaying the data. Should I mock the IDataProvider and verify
that certain methods are called?
Yes, and that their data is fed correctly to the items.
I'm using Scala, but this is a rough translation of the panel.
Thanks, we all should learn Scala anyway so feel free to
post in it ;)
public AccountListPanel(String id, IDataProvider provider) {
Pass in a mock IDataProvider there, and then see that the
accounts that the mock returns get listed on the page.
for (Account account : accountsSuppliedByMockDataProvider) {
assertEquals(account, findItemOf(account).getModelObject());
assertEquals(account.getName(),
findNameLabelOf(account).getModelObjectAsString());
}
Or something like that.
If your repeater initialises lazily, you sometimes have to
call .renderComponent() on it on the test so that its
children get created. But if it already gets its data on
when it's first constructed and started by WicketTester, it
should be rendered and the Items should be there.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
On Sun, 08 Feb 2009, Erick Fleming wrote: private final org.apache.wicket.markup.repeater.data.IDataProvider org.apache.wicket.markup.repeater.data.DataViewBase.dataProvider [class=$Proxy5] protected java.lang.reflect.InvocationHandler java.lang.reflect.Proxy.h [class=org.jmock.lib.JavaReflectionImposteriser$1] - field that is not serializable I know Wicket likes everything to be serializable so does this mean that mocking frameworks are not compatible by default? Yep, this might be an issue -- we have worked around it by using HttpSessionStore in unit tests (I think that it is done by overriding Application.newSessionStore()) in the tests. If the mocked dependency is behind a serialisable proxy (that e.g. wicket-ioc does automatically) it might work right awat. In your case it would mean mocking only the DAO or some such dependency of the data provider that takes care of getting the data. Your test (well, spec) looks good! one(accountProvider).iterator(anyInt, anyInt) one(accountProvider).size one(accountProvider).detach Once it's working you migh twant to make accountProvider return some data, too. Best wishes, Timo - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Testing DataView
Looking for samples or advice for unit testing DataViews. I've been using ListViews, since they are easy to test. Thanks
Re: Testing DataView
On Thu, 05 Feb 2009, Erick Fleming wrote: Looking for samples or advice for unit testing DataViews. I've been using ListViews, since they are easy to test. What exactly do you want to test? That the data rendered is displayed correctly? Can you show some example code that you'd like to test? There shouldn't be anything special about it, you should abstract out how the dataview gets it data, for example by using dependency injection, and provide the data in the test. Best wishes, Timo -- Timo Rantalaiho Reaktor Innovations OyURL: http://www.ri.fi/ - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Testing DataView
I'm new to unit testing and just trying to get my feet wet. The actual code
under test would be a panel that should display some data. I guess I don't
really care to test wicket's dataview but whether or not my panel is
actually displaying the data. Should I mock the IDataProvider and verify
that certain methods are called?
I'm using Scala, but this is a rough translation of the panel.
public class AccountListPanel extends Panel {
private IDataProvider _provider;
public AccountListPanel(String id, IDataProvider provider) {
super(id);
_provider = provider;
add(new DataView(list, provider) {
public void populateItem(Item[Account] item) {
Account account = item.getModelObject();
item.add(new Label(name, account.getName().toString()));
}
}
}
}
On Thu, Feb 5, 2009 at 5:47 PM, Timo Rantalaiho timo.rantala...@ri.fiwrote:
On Thu, 05 Feb 2009, Erick Fleming wrote:
Looking for samples or advice for unit testing DataViews. I've been
using
ListViews, since they are easy to test.
What exactly do you want to test? That the data rendered
is displayed correctly?
Can you show some example code that you'd like to test?
There shouldn't be anything special about it, you should
abstract out how the dataview gets it data, for example by
using dependency injection, and provide the data in the
test.
Best wishes,
Timo
--
Timo Rantalaiho
Reaktor Innovations OyURL: http://www.ri.fi/
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
