Приемочные тесты для Tetris при использовании Test Driven Development

Я хочу попробовать реализовать игру Tetris с помощью TDD.

Из того, что я понял, прочитав Развитие объектно-ориентированного программного обеспечения , Руководствуясь тестами, я должен начать с определения того, какими будут мои приемочные тесты. Если я прав, приемочные тесты при выполнении TDD определяются так же, как варианты использования.

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

Я выбрал следующие 2 приемочных теста в качестве первых для реализации:

  1. Игра начинается, и Игрок закрывает ее.
  2. Игра начинается, и игрок ничего не делает. В конце концов он проигрывает.

Являются ли эти 2 приемочных теста хорошими начальными тестами? Какие были бы хорошие следующие приемочные испытания? Я мог бы подумать о чем-то вроде

  • Игра начинается, и выпадают только квадратные фигуры. Игрок расставляет их все таким образом, что линии всегда «взрываются», из-за чего Игра после 100 игровых шагов еще не окончена.

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

Кроме того, я чувствую искушение просто попытаться реализовать все за один раз при выполнении (2), что, я думаю, не притворяется при реализации второго приемочного теста. Думаю, идея заключалась бы в том, чтобы реализовать игру только после 6-7 из них, а не во время второго. Я прав?

Спасибо


java c# tdd acceptance-testing
person devoured elysium    schedule 24.07.2010    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Я бы сначала подумал об игровом поле и о том, как оно выглядит после того, как несколько кадров с некоторыми определенными блоками были удалены. Например, используя Cucumber:

Scenario: dropping the first square
  Given an empty 10x2 field

  When a square is dropped at column 4
  And 48 frames have passed

  Then the field should contain a square at (4, 1)

  When 48 frames have passed
  Then the field should contain a square at (4, 2)

Scenario: Dropping a square on a full stack
  Given an empty 10x2 field
  And a square at (4, 2)

  When a square is dropped at column 4
  And 48 frames have passed

  Then the game should be over

Если вам нравится внешний вид спецификаций функций Cucumber, вы можете попробовать Cuke4Nuke для .Net. или Cuke4Duke для Java.

person Bryan Ash    schedule 24.07.2010
comment
Я не понимаю, откуда берется число 48. Кроме того, для второго сценария должна ли фраза Given быть предоставлена ​​вместо полного поля 10x2? - person SCFrench; 24.07.2010
comment
Я просмотрел страницу Тетриса в Википедии, чтобы получить деловой язык. Вот откуда взялось число 48. полное поле 10x2 может быть хорошим, но не очень реалистичным, я немного играл в тетрис в свое время и НИКОГДА не видел полного поля. - person Bryan Ash; 24.07.2010
comment
У меня есть некоторые проблемы с пониманием того, как использовать TDD, который говорит, что для каждого теста нам нужно минимально возможное количество кода, чтобы просто что-то запустить, если мы реализуем сценарии, которые вы дали. Я имею в виду, что я мог бы уже реализовать полную игру тетрис, но мне сложно понять, как реализовать только то, что нужно, без необходимости помещать все это туда уже. - person devoured elysium; 24.07.2010
comment
То, что я показал, было бы приемочным тестом. Начните с приемочного испытания. Если вы уверены, что сможете реализовать большую часть функции без ошибок, дерзайте. Если поведение менее тривиально, напишите первый тест более низкого уровня и пройдите его. Потом следующий. Если вы все еще приближаетесь к критериям приемки, продолжайте двигаться, если нет, УДАЛИТЕ код и начните заново. Иногда я пару раз прохожу путь модульного теста (низкоуровневая спецификация), прежде чем понимаю, как должен быть написан код. Слушай внимательно, оно тебе расскажет. - person Bryan Ash; 25.07.2010
comment
В чем разница между теми приемочными тестами, которые вы сделали, и модульными тестами для класса Tetris? - person devoured elysium; 25.07.2010

arrow_upward
2
arrow_downward

Вы захотите удалить случайность, которая принадлежит вашей игре, из ваших тестов. Да, это означает, что тест не полностью повторяет игру, но это также означает, что у вас есть повторяемые тесты, и это имеет большую ценность. Изолируйте различия — передайте PieceProvider в свою игру; для реальной игры используйте RandomPieceProvider, а для тестов — SpecifiedPieceProvider. Итак, у вас есть лишь крошечная разница между ними, но разница должна быть настолько малой, чтобы не иметь значения; вы все еще можете с уверенностью протестировать все остальные аспекты игры.

person Carl Manaster    schedule 24.07.2010
comment
Конструктор public Random(long seed) упрощает создание воспроизводимого, но правдоподобного теста: download.oracle.com/docs/cd/E17409_01/javase/6/docs/api/java/ - person trashgod; 24.07.2010
comment
Да это правда. Но больше меня беспокоит то, как реализовать первый сценарий/прецедент. Вопрос в том, насколько я должен реализовать саму игру. - person devoured elysium; 24.07.2010
comment
@devoured Я не читал упомянутую вами книгу, но большинство советов, которые я видел в отношении TDD, таковы: достаточно, чтобы пройти тест. Это сработало хорошо для меня. - person Carl Manaster; 24.07.2010

arrow_upward
0
arrow_downward

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

person emory    schedule 24.07.2010
comment
Как я могу знать, что они не складываются правильно? Разве тогда мне не пришлось бы реализовывать более сложную логику кода, чем та, которую я пытаюсь сделать? Или вы предполагаете, что я просто добавляю в игру набор выбранных фигур? Вы говорите о модульных тестах или приемочных тестах? - person devoured elysium; 24.07.2010
comment
Я предполагал набор выбранных фигур. - person emory; 24.07.2010