В перспективе модульного теста: должен ли вид указывать презентатора или наоборот в GWT MVP? - PullRequest
Новая
       43

В перспективе модульного теста: должен ли вид указывать презентатора или наоборот в GWT MVP?

3 голосов
/ 30 апреля 2011

В руководствах по GWT Google использует разные подходы для выполнения MVP, либо View указывает Presenter, либо Presenter указывает View.Первый используется при использовании «Деятельности» и «Места».

Этот пост затрагивает эту тему: MVP: Должен ли View реализовать интерфейс докладчика или наоборот?Я хотел бы знать, какой вариант вы считаете лучшим, когда речь идет о модульном тестировании докладчика и представления?Или оба будут работать одинаково хорошо?

Ответы [ 3 ]

4 голосов
/ 01 мая 2011

Идея, лежащая в основе модульного тестирования презентатора, заключается в том, чтобы смоделировать представление и написать несколько утверждений относительно состояния этого смоделированного представления, которое будет визуально представлено в реальном приложении. Благодаря такому подходу нет необходимости запускать полный GWTTestCase, который занимает много времени и должен быть скорее отнесен к категории интеграционного тестирования, а не модульного тестирования.

Если вы попробуете оба подхода MVP, модульные тесты могут выглядеть следующим образом:

MVP 1: 

@Test
public void shouldAddContactOnAddContactClicked() {
    // given
    ContactsPresenter.Display display = mock(ContactsPresenter.Display.class);
    MockButton addButton = new MockButton();
    given(display.getAddButton()).willReturn(addButton);
    ContactsDisplay.Presenter presenter = new ContactsPresenter();
    presenter.bindView(display);
    presenter.setContacts(new ArrayList<Contact>());

    // when
    addButton.click();

    // then
    verify(display).addContact(any());
    assertThat(presenter.getContacts().size(), is(1));
}

Где MockButton - это то, что я описал здесь: Комплексные плюсы / минусы Mocking Frameworks для GWT

Хотя это возможно, на самом деле это не очень удобно для насмешек. Подход MVP2, кажется, работает лучше: 

@Test
public void shouldAddContactOnAddContactClicked() {
    // given
    ContactsView view = mock(ContactsView.class);
    ContactsView.Presenter presenter = new ContactsPresenter();
    presenter.bindView(view); // assuming that presenter will call view.setPresenter(this)
    presenter.setContacts(new ArrayList<Contact>());

    // when
    presenter.onAddContactClicked();

    // then
    verify(view).addContact(any()); 
    assertThat(presenter.getContacts().size(), is(1));
}

Другой причиной использования второго подхода является проблема в MVP1 с объявлением элементов дисплея, которые будут вызывать различные события (например, ClickEvent, FocusEvent). MVP2 также облегчает работу, когда дело доходит до UiBinder.

3 голосов
/ 01 мая 2011

Избегайте использования HasXxxHandlers, т. Е. Используйте подход из статьи part 2 , где каждый пир имеет ссылку на другого. HasXxxHandlers слишком сложны для насмешки, особенно при использовании насмешливых библиотек, таких как Mockito или EasyMock. Для лучшей тестируемости вы должны внедрить представление в докладчика, а затем вызывающий вызовет метод представления setPresenter или setDelegate (таким образом, вы можете выполнить модульное тестирование, если вы правильно вызываете этот метод в нужное время ). При использовании «Активности», где ваша деятельность является докладчиком, вы, скорее всего, будете звонить view.setPresenter(this) в start и view.setPresenter(null) в onStop и onCancel; таким образом, вы можете использовать одноэлементное представление для нескольких докладчиков (хотя, очевидно, не более чем для одного).

0 голосов
/ 01 мая 2011

В модульном тесте это действительно не имеет значения.Если вы спроектируете это правильно, это просто вопрос, где вам нужно вставить заглушку (или макет).Модульное тестирование не должно позволять определять проектные решения.Тем не менее, юнит-тест часто показывает, является ли конструкция неправильной (например, отсутствует инъекция и т. Д.)

...