Достижимо ли полное регрессионное тестирование с помощью Behavior Driver Development. (Jbehave/огурец)

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

Рассмотрим эти критерии приемлемости:

Товары могут быть заменены или возвращены.

Это приводит к двум сценариям; один, где мы возвращаем товар, и один, где мы возвращаем его. Теперь давайте добавим к этому еще немного:

Товары помещаются на склад при возврате или возмещении, если они не неисправны.

Теперь у нас есть четыре сценария:

• Тот, где мы заменяем товар, и он неисправен
• Тот, где мы возвращаем товар, и он неисправен
• Тот, где мы заменяем товар и возвращаем его на склад
• Тот, где мы возвращаем товар и возвращаем его на склад.

Теперь давайте добавим критерии, по которым квитанция должна быть в дате. Мы должны убедиться, что в возмещении и замене отказано, а также в том, что товар случайно не вернулся на склад, а также в том, что на нем напечатана какая-либо этикетка с дефектом. Итак, теперь у нас есть восемь сценариев.

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

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

Мы надеемся, что код хорошо спроектирован и что различные аспекты поведения хорошо инкапсулированы. Мы надеемся, что были рассмотрены все сценарии. Однако если бы это было так, мы бы не изменили поведение случайно, чего не хотели, и нам вообще не понадобилось бы регрессионное тестирование. Итак, мы знаем, что, по крайней мере, в большинстве команд изменения в одном сценарии влияют на изменения в другом.

Размышление об ответственности каждого фрагмента кода может помочь уменьшить это, поэтому большинство команд практикуют как BDD, так и TDD (или BDD на уровне класса).

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

Единственное, что мы можем сделать, это получить уверенность в том, что код работает.

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

Таким образом, BDD определенно может помочь с регрессионным тестированием... но ничто, даже BDD, не может обеспечить полное покрытие регрессионными тестами.