RSpec Пример - Теннис Класс футбола

Question

В книге «Programming Ruby 1.9/2.0» автор приводит пример класса Tennis Scorer, который будет разработан путем написания некоторых тестов RSpec до фактического кода.

Автор вводит 4 теста:

it "should start with a score of 0-0" 
it "should be 15-0 if the server wins a point" 
it "should be 0-15 if the receiver wins a point" 
it "should be 15-15 after they both win a point" 

, а затем автор предполагает, что читатель должен идти вперед и завершить класс с написания тестов, как это:

it "should be 40-0 after the server wins three points" 
it "should be W-L after the server wins four points" 
it "should be L-W after the receiver wins four points" 
it "should be Deuce after each wins three points" 
it "should be A-server after each wins three points and the server gets one more" 

(фактический TennisScorer класса добавляет оценки для каждого игрока и возвращает их в формате «15-15»).

Предполагает ли автор, что код будет работать на 100% для таких баллов, как 30-15, 15-30, 0-30, 30-0 и т. Д., Пока тест будет успешным для 15-0, 0- 15 и 15-15? Другими словами, нет необходимости проверять каждую возможную оценку явно? Автор предлагает тест 40-0, который имеет смысл, потому что 40 разрывает 0-15-30 конвенций (оценка * 15), так что 40-0 тест достаточно, чтобы показать, что 40-30, 15-40 и т. Д. работать также?

Кроме того, может быть, я преувеличиваю это, но разве не имеет смысла иметь «случайную игру» в моем тесте, где я добавляю случайные оценки 100000 раз и динамически сравниваю результат? (но, я думаю, тогда мой тест мог бы содержать некоторые ошибки легко??). Я полагаю, что это был бы путь, если бы я написал тест для метода умножения, например (или я тогда просто проверил бы, если 1 * 2 = 2 и предположим, что все работает нормально?)

Answer 1

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

Со спецификацией выше код может не работать с 30-15 и так далее, как вы указываете. Это зависит от того, как получается реализация. Было бы целесообразно добавить еще несколько спецификаций и повторно использовать тестовый код внизу.

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