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

Question

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

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

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

РЕДАКТИРОВАТЬ: Я довольно плохо знаком с TDD, но я получил базовый и сделал несколько кат

Answer 1

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

known_player.rpi.should == 0.6902

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

Answer 3

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

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

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

Попробуйте проверить эти TDD ката Роя Ошерова, который написал фантастическую книгу Искусство модульного тестирования .

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