• Yoda Magister

Когда тестирование и разработка объединяются



Когда тестирование и разработка объединяются

Идея данной статьи пришла ко мне когда я начал работать в новом стартапе chous.ai. Так как, у нас объеденен отдел ручного и автоматизированного тестирования, остро стал вопрос унификации тестовой документации. Так как в автоматизации мы используем BDD, возникла идея перенести этот опыт и на ручное тестирования, заменив тест-кейсы сценариями. Так как найти серьезной документации по этой теме на русском языке я не смог, написал данную статью, подробно описывающую имплементацию подходов TDD и BDD к QA процессу.

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

Но даже зная все это, мы еще очень далеки от того времени, когда написание тестов до-написания кода станет общим стандартом. Точно так же как TDD стало следующим этапом эволюции развития экстремального программирования (eXP) и выдвинуло на первый план инфраструктуру для unit-тестирования, следующий скачок эволюции был сделан с того уровня, где находится TDD. В этом случае эволюционировали от TDD к его интуитивному родственнику: behavior-driven development (BDD) – разработке, основанной на функционировании. Но давайте обо всем по порядку.

Разработка через тестирование - TDD

Разработка через тестирование (англ. test-driven development, TDD) - это современный стандарт разработки программного обеспечения, который основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам. Кент Бек, считающийся изобретателем этой техники, утверждал в 2003 году, что разработка через тестирование позволяет быть уверенным продкутивности своего кода, что в конечном счете уменьшает общее время разработки. В 1999 году при своём появлении разработка через тестирование была тесно связана с концепцией «сначала тест» (англ. test-first), применяемой в экстремальном программировании, однако позже выделилась как независимая методология. В основе лежит unit-Тест это программная процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. ​ Технику TDD легко представить данной схемой:


Теперь я более подробно объясню как это работает:

1. На основе спецификации, мокапов и другой исходной документации пишется тест. Для программы которая еще даже не написана. Если запустить такой тест, логично, что он упадет.

2. Программист пишет код, создает программу, при этом тест будет индикатором. Как только тест будет пройден - код готов.

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

Данный цикл может повторятся n раз, до того как программа не достигнет желаемого состояния.

Разработка, основанная на поведении

После того как мы узнали, что современные методики разработки объединяются с тестированием образуя TDD. Далее TDD эволюционировало образовав BDD (behavior-driven development) или разработка через поведение. Скорее всего вас уже запутали эти аббревиатуры и все слилось в сплошное BDSM.

Но давайте обратимся к мнению экспертов.

Мэтт Уинн, один из разработчиков интерпретатора BDD для фреймворка Cucumber Limited передает суть технологии так:

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

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