Хороший пример / ссылка на использование TDD с Model View Presenter с использованием Rhino Mocks - PullRequest
3 голосов
/ 02 июня 2009

Цените любой хороший пример или ссылки на веб-сайты, на которых есть полезная информация об использовании TDD с шаблоном Model-View-Presenter с использованием Rhino Mocks.

Я ищу в отношении следующих пунктов

  • Что издеваться (просмотр и ведущий)
  • Новый синтаксис AAA
  • Как издеваться над поведением интерфейса? например если "firstName" и "lastName" введены в поле зрения, включите Кнопка «Отправить», иначе отключите ее. Это простой пример.
  • Лучшие практики

Любой вклад в этом направлении приветствуется.

Заранее спасибо.

Ответы [ 2 ]

4 голосов
/ 04 июня 2009

Поскольку у вас нет ответа, я приложу все усилия к тому, чему я научилась до сих пор;

Первый вопрос; что издеваться - как правило, вы будете высмеивать все, что вы не тестируете. Итак, если вы тестируете ViewModel, вы должны будете смоделировать код представления, который изменяет ViewModel, вместе с поддельным кодом Model, который заполняет / сохраняет ViewModel.

Второй вопрос; Синтаксис AAA. Синтаксис AAA легче всего поддерживать, добавляя комментарии следующего типа к вашим методам тестирования:

[Test]
public void whenUserFillsInFirstAndLastName_ThenUserCanSubmit()
{
    // Arrange - code used to set-up what you are testing.
    this.loadViewModelWithInitalContext(viewModel); // This is a helper that loads the viewmodel

    // Act - code to fullfil the 'when' part in the test.
    this.viewModel.FirstName = "test";
    this.viewModel.LastName = "me";

    // Assert - code to check state of object being tested. (here I am testing a property that I bind to the enabled state of a submit type button)
    Assert.IsTrue(this.viewModel.UserCanSubmit);
}

Третий вопрос, фиктивное поведение пользовательского интерфейса - обычно вы помещаете это в часть теста Act (для тестирования ViewModel).

Последний вопрос, лучшие практики, мой опыт говорит;

  • Одновременно утверждайте только одну вещь, тогда ваши тесты не пройдут с одним провалом, и вы сэкономите много времени, выясняя, что пошло не так. Вы могли бы даже использовать один метод тестирования для каждого утверждения, но задать новый вопрос о том, как это сделать, поскольку для обеспечения управляемости требуется другая реализация синтаксиса AAA.
  • Использовать внедрение зависимостей, поскольку оно облегчает симуляцию кода.
  • Сделайте ваши тесты как можно более легкими - не переходите на базу данных или диск, вам нужны быстрые тесты, чтобы разработчики выполняли их как можно чаще. Если мне нужно пройти 5 минут, чтобы пройти тесты, мне надоело ждать. Если это займет у меня 10 секунд, я буду делать это гораздо чаще.
  • Последнее - но самое важное - убедитесь, что вы выполняете все свои юнит-тесты при каждой проверке кем-либо из вашей команды. Это позволит поддерживать ваши тесты в актуальном состоянии, а также сделает вашу кодовую базу намного более стабильной. Используйте постоянные платформы интеграции, такие как CruiseControl.net, для построения на отдельном сервере - как можно чаще. Подсказка заключается в том, что вы хотите узнать как можно быстрее, если кто-то / вещь сломал сборку.

Мои рекомендуемые ссылки; используйте «ваш любимый поисковик» для поиска того, что вы хотите сделать, или разместите здесь примеры вашего теста и получите комментарии - это поможет вам улучшить то, что вы делаете.

1 голос
/ 24 июня 2009

У Фила Хаака довольно хорошее сообщение в блоге . Загрузите исходный код и посмотрите на тесты, они довольно хорошо прокомментированы.

...