Пример BDD - зачем тестировать только «счастливый путь»? - PullRequest
Новая
       7

Пример BDD - зачем тестировать только «счастливый путь»?

1 голос
/ 21 декабря 2009

Я случайно наткнулся на старую статью Люка Редпата, в которой представлен очень простой пример BDD (очень короткий и простой для понимания даже для программистов, не являющихся Ruby, как я). Я нашел конечный результат очень неполным, что сделало пример довольно бесполезным.

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

validates_length_of :password, :in => 6..12, :allow_nil => :true

до 

validates_length_of :password, :in => 7..8, :allow_nil => :true

(или даже полностью удалить проверку длины пароля) тест все равно будет пройден, но вы, очевидно, видите, что код теперь нарушает первоначальные требования.

Я просто думаю, что последнего рефакторинга, состоящего из помещения всех отдельных тестов в один, просто недостаточно. Он проверяет только «счастливый путь», который не гарантирует многого. У меня были бы абсолютно все тесты, которые подтверждают, что корректная ошибка вызвана определенными значениями. В случае с паролем я бы проверил, что пароль длиной менее 6 и больше 12 является недействительным и вызывает соответствующую ошибку. Тест «счастливого пути» тоже будет там, но не один, как в статье.

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

Ответы [ 3 ]

1 голос
/ 22 декабря 2009

Я не совсем понимаю ваш вопрос.Спецификации do содержат ожидания относительно длины пароля, как для «счастливого пути» , так и для двух разных режимов отказа (слишком длинный пароль и слишком короткий пароль): 

specify "should be valid with a full set of valid attributes" do
  @user.attributes = valid_user_attributes
  @user.should_be_valid
end

Это заботится о счастливом пути, поскольку valid_user_attributes содержит действительный пароль. 

specify "should be invalid if password is not between 6 and 12 characters in length" do
  @user.attributes = valid_user_attributes.except(:password)
  @user.password = 'abcdefghijklm'
  @user.should_not_be_valid
  @user.password = 'abcde'
  @user.should_not_be_valid
end

И это проверяет два режима отказа.

Конечно, отсутствует один граничный случай(12 символов), но это не так уж и плохо.

0 голосов
/ 21 декабря 2009

BDD (и TDD) являются дизайн деятельность. Тесты предназначены для разработки дизайна кода, а не для гарантии того, что он не содержит ошибок. Для этого должны быть независимые тестеры. Поэтому нам нужна приличная степень охвата, чтобы гарантировать, что наш код работает должным образом и обрабатывает исключения в чистом виде. Но TDD не требует, чтобы мы писали модульные тесты для каждого возможного крайнего случая.

Что касается приведенного вами конкретного примера, возможно, ему следовало кодировать два теста, один с паролем из шести символов, другой с паролем из двенадцати символов. Но какой в ​​этом смысл? Мы знаем, что требование , пароль должен быть длиной от 6 до 12 символов . Если мы неправильно поняли требования и считаем, что правило должно быть ... 

validates_length_of :password, :in => 7..8, :allow_nil => :true

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

Точно так же мы могли бы удалить тест, проверяющий длину пароля в целом, но какой в ​​этом смысл? Тесты призваны помочь нам правильно реализовать spceification. Если у нас нет тестов для каждого фрагмента кода, который мы пишем, то мы не делаем TDD / BDD.

0 голосов
/ 21 декабря 2009

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

...