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
protected ContactsDatabase getContactsDB()
public Iterator<Contact> iterator(long first, long count)
List<Contact> contactsFound = getContactsDB().getIndex(getSort());
subList((int)first, (int)(first + count)).
I mocked the iterator method. But you are saying that I should mock the
On Thu, Jan 12, 2017 at 11:10 AM, Bas Gooren <b...@iswd.nl> wrote:
> 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:
> SortableDataProvider, in
> package org.apache.wicket.extensions.markup.html.repeater.util, has a
> 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!