Hi Eric,
Well - looking at SortableDataProvider I suppose you cold mock an
implementation of it. As getSortState() is final, you need to trust that it
does it’s job. Why do you want to mock that method?
The same applies to LoadableDetachableModel - why do you need to mock final
getObject(), which has a know contract/implementation?
In general I’m not sure I understand yet why you are mocking your
SortableContactDataProvider.
If you want to test that your SortableContactDataProvider does it’s job
properly, provide it with a mock database so you can verify that it makes
all expected calls.
Since you are using a static call to locate your database, you could
introduce a way to force a ContactsDatabase for the current thread in your
locator class.
For example (pseudocode for a unit test):
… run before test
ContactsDatabase mockDatabase = createMock(…)
DatabaseLocator.setDatabaseForCurrentThread(mockDatabase)
… in test
expect(mockDatabase.getIndex(anyObject())).andReturn(…)
SortableContactDataProvider.iterator(….)
etc.
… run after test
DatabaseLocator.clearDatabaseForCurrentThread()
Met vriendelijke groet,
Kind regards,
Bas Gooren
Op 13 januari 2017 bij 12:10:03, Eric J. Van der Velden (
ericjvandervel...@gmail.com) schreef:
Hoi Bas,
Thank you for your answer!
So maybe I am doing it wrong.
Let's take an example. In the wicket examples, in package
org.apache.wicket.examples.repeater, there is the provider:
public class SortableContactDataProvider_my extends
SortableDataProvider_my<Contact, String> implements
IFilterStateLocator<ContactFilter_my>
{
...
protected ContactsDatabase getContactsDB()
{
return DatabaseLocator.getDatabase();
}
@Override
public Iterator<Contact> iterator(long first, long count)
{
List<Contact> contactsFound = getContactsDB().getIndex(getSort());
return filterContacts(contactsFound).
subList((int)first, (int)(first + count)).
iterator();
}
I mocked the iterator method. But you are saying that I should mock the
getContactsDB method?
Thank you.
On Thu, Jan 12, 2017 at 11:10 AM, Bas Gooren <b...@iswd.nl> wrote:
> Eric,
>
>
> All of our data providers use an external source to load the actual data,
> e.g. a repository or dao.
>
> As all of our repositories and daos are interfaces, those are easy to mock.
>
>
> Testing the provider is then simply a matter of ensuring the right
> methods, with the right parameters are called on the mocked objects.
>
>
> What functionality in your (custom) data providers do you have that you
> want to test? In general I would say that final methods in a known and
> tested library (wicket) do not need to be tested anyway - that is the
> responsibility of the library.
>
> Met vriendelijke groet,
> Kind regards,
>
> Bas Gooren
>
> Op 12 januari 2017 bij 10:23:12, Eric J. Van der Velden (
> ericjvandervel...@gmail.com) schreef:
>
> Hello,
>
> SortableDataProvider, in
> package org.apache.wicket.extensions.markup.html.repeater.util, has a
> final
> method getSortState().
>
> I cannot mock this method.
>
> I have copied SortableDataProvider under a different name, and subclassed
> this one,but I do not like this.
>
> The same happens with final LoadableDetachableModel.getObject(), but in
> this case I could mock LoadableDetachableModel.load().
>
> So why are these methods final, and how do programmers test the provider?
>
> Thank you!
>
>
