Какой минимальный первый тест я должен написать, чтобы начать в BDD? - PullRequest
Новая
       22

Какой минимальный первый тест я должен написать, чтобы начать в BDD?

0 голосов
/ 22 мая 2019

Я изучаю BDD и пытаюсь сделать очень простую игру. Игрок видит некоторую форму многоугольника и должен угадать его площадь, расширяя круг. Чтобы угадать, игроку нужно некоторое время удерживать палец на экране (мобильная игра), чтобы расширить круг до нужного размера. Если область круга находится рядом с областью формы, выигрывает thep player.

Теперь я хочу создать первый минимальный тест, чтобы начать разработку, но я не могу понять этот тест. Это самый простой тест, который я пишу (в стиле bdd): 

public partial class GuessShapeSize_Feature
    {
        [Test]
        public void RightGuess_Scenario()
        {
            Given_expanding_spot_expand_speed_is (5.0f);
            Given_shape_has_area_of (15.0f);
            When_player_holds_finger_for_seconds (3.0f);
            Then_player_guess_result_is (GuessResult.Success);
        }
    }

Проблема здесь в том, что это сложный тест, который требует около 5 классов: Уровень (контейнер для всего, что происходит здесь и проверка результата), Форма (чтобы угадать), PlayerInput (удерживать и отпустить палец), CircleSpot (который расширяется время), TimeManager (мне нужно, чтобы прошло 3 секунды).

Я не могу назвать этот тест действительно простым для первого теста. Но я не могу представить более простой тест. Что мне делать в этой ситуации?

Ответы [ 2 ]

1 голос
/ 23 мая 2019

Вам не нужно 5 классов для первого ответа.Все, что вам нужно, это пустой API или пользовательский интерфейс, и что-то, что всегда возвращает GuessResult.Success.

Диспетчер времени будет использоваться только из сценария (и всегда установлен на 3 секунды).на данный момент).

Если это поведение недостаточно богато (ну, конечно, это не так!), то какой сценарий будет дальше?Можете ли вы вспомнить пример, в котором ваша игра должна возвращать что-то отличное от GameResult.Success?

Начните с создания по одному сценарию за раз самым простым способом.Когда этого не достаточно, измените его.

Абсолютно хорошо иметь в виду классы вашего дизайна, но сделать его простым и рефакторингом, когда вы идете к этому дизайну.

Разбивая другие классы, вы будете делегировать части поведения системы этим классам.Некоторые вещи будут лучше выражаться в виде поведения классов, чем всей системы (например, правила расчета площади), поэтому напишите пример того, как класс ведет себя с точки зрения API / UI (TDD).Это «внешняя сторона» BDD.

Это поможет вам сохранить хорошую тестовую пирамиду (множество юнит-тестов, несколько сценариев).

Не забудьте поговорить скто-то о том, что ты делаешь, даже если это резиновая утка.

1 голос
/ 22 мая 2019

Думайте меньше, что означает: посмотрите на «строительные блоки», которые требуются вашему общему опыту:

  • Вам нужно расширение. А как насчет теста, который просто проверяет, что у вас есть такая расширяющаяся вещь?
  • Тогда: эта точка расширения в какой-то момент достигнет жесткого предела. Итак, напишите тест, чтобы убедиться, что спот растет до этого предела, но не за его пределами.
  • Следующая вещь: пользовательский ввод. Напишите тест, показывающий растущую форму, и протестируйте необходимые взаимодействия с пользователем (не принимая решения о выигрыше или проигрыше)
  • И затем, когда все это сработает, вы сможете вернуться к тесту, который у вас уже есть: полный пользовательский опыт, возможно, с различными вариантами, чтобы представить выигрышный или проигрышный случай.
...