TDD - Как проверить простой список получателей

Question

Я действительно смущен. Скажем, моя история пользователя выглядит так.

«Пользователь должен уметь смотреть статистику каждого игрока в лиге, чтобы он мог разведать ».

Возможно, история пользователя плоха, но все же как я могу предположить, что TDD? Должен ли я протестовать против имущества, которое я ожидаю? Я действительно потерялся здесь и буду признателен за вашу точку зрения.

EDIT: Я довольно новый для TDD, но я получаю основной и сделал несколько ката

Answer 1

То, что вы описываете, на самом деле не достаточно тонкое для TDD в коде, но вы можете сломать его.

Прежде всего, как они будут представлены с информацией, необходимой им для поиска? Они собираются увидеть все статистические данные? Поиск игрока? Поиск конкретного стата? Это дает вам более тонкое поведение, и теперь вы можете начать думать о интерфейсе, который пользователь будет использовать. Подумайте только один пример того, что пользователь делает - возможно, поиск игрока, возможно, посещение первой страницы и т. Д. Сделайте что-то интересное, но простое.

Как только вы узнаете, как будет выглядеть эта часть пользовательского интерфейса, вы можете ее закодировать. (Вы может TDD, но, как правило, интерфейс немного меняется, а автоматизация пользовательского интерфейса сложна, поэтому большинство людей не поддерживают TDD UI).

Пользовательский интерфейс захочет получить некоторую информацию откуда-нибудь и передать некоторую информацию обратно. Вы обнаружите, что думаете о сотрудничающем классе - вероятно, о контроллере или ведущем, - который поможет интерфейсу. В свою очередь, этот контроллер захочет контролировать взаимодействие между некоторыми другими классами - сам пользовательский интерфейс, репозиторий статистики игроков, безопасность, валидация и т. Д. Это первый класс, на который вы будете писать тесты.

Теперь вы можете начать запись теста для контроллера. Вы уже знаете, как UI собирается его использовать. Просто напишите пример того, как другой класс может использовать контроллер таким же образом, какую информацию требуется контроллеру и какой результат вы получите, когда используете его.

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

В какой-то момент контроллер будет готов что-то сделать, но вы все еще не можете запустить приложение, потому что вы еще не закончили кодировать классы сотрудничества - они все еще просто интерфейсы. Сделайте то же самое снова для них - притворяйтесь, что вы являетесь контролером, используя их, и если им нужны какие-либо другие классы, издеваются над ними или их заглушить.

В конце концов у вас не будет классов для издевки или заглушки, и будет запущен первый сценарий в пользовательском интерфейсе. Если вы хотите получить более быструю обратную связь, в любой момент вы можете просто скопировать некоторые данные, чтобы пользовательский интерфейс работал, и вы можете видеть, как он выглядит.

Выполнение этого способа называется снаружи в, и связано с BDD, несколько иным образом мышления о TDD. Я надеюсь, что this page может вам помочь.

Answer 2

У вас есть это в основном правильно. Вы не указали, есть ли у вас предыдущий опыт модульного тестирования или TDD, поэтому я не знаю, как много из того, что будет дальше, будет восстановлением для вас.

Вы начинаете с написания теста, который, как вы знаете, терпит неудачу. В приведенном примере, скажем, ваш класс Player не имеет поля Stats. Таким образом, вы пишете тест, чтобы убедиться, что вы можете получить доступ к полю Stats. Это провалится; он может даже не построить, потому что вы ссылаетесь на поле, которое еще не существует. Затем вы добавляете поле. Тест проходит. Затем цикл начинается снова.

Предположим, что у вас есть определенный стат, рассчитанный на основе других характеристик. Вы пишете неудачную проверку теста на наличие этого стата, прежде чем вы напишете логику, чтобы даже вычислить ее. Это провалится. Вы реализуете логику для генерации статистики. Тест проходит. Повторение.

Попробуйте просмотреть эти TDD kata от Roy Osherove, который написал фантастическую книгу Art of Unit Testing.

Надеюсь, это поможет!

Answer 3

Здесь вам нужно создать задачи, которые описывают реальные шаги немного лучше. Каждой задаче, как правило, не нужно больше 12 часов для завершения. Например, задача может быть: «Добавить RPI в столбец на страницу« Список игроков ». Отсюда вы можете начать писать тесты.

Предполагая, что вы используете некоторую среду MVC, вы можете написать тест, который проверяет, может ли ваша модель сообщать RPI. Затем вы можете написать тест, чтобы убедиться, что ваш контроллер подает RPI в представление. И, наконец, вы можете написать тест, чтобы убедиться, что ваше представление отобразит RPI, когда оно будет предоставлено.

В Rails я бы добавил известный RPI в тестовую базу данных для известного игрока до начала фактического теста. Затем я могу написать единичный тест, который выглядит следующим образом:

known_player.rpi.should == 0.6902 

Все эти тесты потерпят неудачу. Затем, когда вы начнете выполнять каждую фактическую функцию, вы должны снова запустить свои тесты и посмотреть, как они начнут проходить.