Имеет ли смысл писать логические тесты с использованием JBehave?

Question

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

Исходя из этого, я попросил тестировщика написать истории для тестового приложения (игра в боулинг Kata от Uncle Bob). В конце дня мы попытаемся сопоставить его тесты с игрой в боулинг.

Я ожидал такого теста:

Given a bowling game
When player rolls 5
And player rolls 4
Then total pins knocked down is 9

Вместо этого, тестер пришел с «логическими тестами», другими словами, он не был таким конкретным. Но, по его словам, это был действительный тест.

Given a bowling game
When player does a regular throw
Then score should be calculated appropriately

Моя проблема с этим - двусмысленность, что такое «обычный бросок»? Что такое «соответственно»? Что это будет означать, если один из этих шагов потерпит неудачу?

Однако, тестер говорит, что человек понимает и что то, что я искал, где «физические тесты», которые куда труднее написать.

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

Так что мне интересно, как вы подходите к этому? Как вы пишете свои тесты JBehave? И есть ли у вас опыт, когда не вы пишут эти тесты, и вы должны сопоставить их с вашим кодом?

Answer 1

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

Вы должны были в паре с ним написать первые тесты, чтобы поставить его в правильном направлении.Возможно, вы могли бы дать ему свой тест и попросить его увеличить охват, добавив новые тесты.

Answer 2

Я ненавижу такие смутные слова, как "соответственно" в "ожидаемых значениях" . «Соответственно» является просто примером «ядовитого слова» для тестирования, и если его не исключить, этот «подход» может получить широкое распространение, эффективно убивая тестирование в целом. Это может быть «достаточно» для человека-тестировщика, но такие «тестовые случаи» приемлемы только при первых попытках исследовательского «теста на дым».

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

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

Но "пустой шаблон тестового сценария"? Он также имеет некоторое значение: это «шаблон сценария», пустой скелет, подготовленный для заполнения данными: поэтому я люблю называть эти ситуации «DDT»: «Тестирование на основе данных».

Представьте себе веб-форму для тестирования, с проверками на 10 входах, с перекрестными проверками ... и кнопкой отправки. Для каждого входа может быть 10 тестовых случаев:

• пусто;
• с символом, но все равно слишком коротким;
• слишком долго для сервера, но разрешено в форме для копирования-вставки и дальнейшего редактирования;
• с недопустимыми символами ...

Подход, который я рекомендую, состоит в том, чтобы подготовить набор передаваемых данных: даже для их генерации (из БД или даже случайным образом) все, что вы можете предсказать, должно пройти тест, «счастливый сценарий». Храните данные в стороне, как шаблон данных, и используйте их для инициализации формы, ее заполнения, а затем для устранения некоторого единственного значения: создайте контрольные примеры «для сбоя». Сделайте это, то есть 10 раз для каждого отдельного ввода, для каждого из 10 входов (100 тестовых случаев даже до того, как были предприняты перекрестные правила) ... и затем, после 100 раз отказа формы сервером, заполните Форма для передачи данных, не искажая их, поэтому форма может быть окончательно принята. (статус принятого изменения изменений в серверном приложении, поэтому он должен быть последним, чтобы проверить все 101 случай в одном и том же состоянии приложения)

Чтобы выполнить тест таким образом, вам понадобятся две вещи:

• пустой шаблон сценария,
• и таблица из 100 строк данных:
  • 10 столбцов входных данных: манипулируя только одним значением, передавая строку за строкой вниз по таблице (т. Е. Когда-либо слышали о сером коде?),
  • возможно сохранение истории наследования в описании строки, откуда и откуда получена строка, с помощью которой манипулируется значением.
  • Также 11-й столбец, столбец (столбцы) «ожидаемый результат» заполнен: для прохождения / сбоя ожидаемого состояния, ожидаемого сообщения об ошибке / проверки, ссылки на требования, для отслеживания тестового покрытия. (то есть когда-нибудь видел FitNesse?)
  • И, возможно, также столбец для реального обнаруженного результата при выполнении теста, чтобы отслеживать историю отдельного теста. (так уже упоминался сервер CI)

Чтобы объединить «пустой сценарий сценария» с одной стороны и «таблицу данных для проведения теста» с другой стороны, действительно нужен какой-то механизм. И ваши данные должны быть импортированы. Таким образом, вы можете подготовить строки в Excel, которые также могут быть теоретически импортированы, но для более легкой жизни я рекомендую либо CSV, свойства, XML, либо просто любой машиночитаемый формат, текстовый формат.

Answer 3

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

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

Но представьте себе более сложную область, такую ​​как финансы. Для этого, вероятно, было бы лучше иметь более четкие примеры, чтобы обеспечить хорошее понимание требования.

В качестве альтернативы предположим, что у вас есть сценарий:

Given I try to sign up with an invalid email address
Then I should not be registered

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

Answer 4

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

Answer 5

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

Использование jbehave вообще имеет смысл только в том случае, если группа тестирования отвечает за создание тестов с большим количеством информации в них. В противном случае было бы более эффективно взять список TODO и кодировать его в JUnit.