Тестирование при TDD и BDD 23.11.2015

TDD (или test-driven development) — подход к разработке и тестированию, при котором сначала создаются тесты, которым должен удовлетворять код и только потом его реализация. TDD — процесс итеративный. Добавляя в класс что то новое, вы сначала пишите тест на новый функционал и только потом создаёте минимальное количество кода, реализующее нужное поведение. Ни строчкой больше, ни меньше. Добившись успешного прохождения теста, можно задуматься о качестве кода и сделать его рефакторинг.

Следуя TDD, вы получаете следующие преимущества:
— ваш код полностью покрыт тестами;
— cоздавая тесты до написания кода класса, вы заранее задумаетесь об его использовании, что положительно скажется как на качестве внешнего интерфейса класса, так и на архитектуре проекта в целом;
— хорошие тесты могут легко заменить документацию, т.к. наглядно демонстрируют использование трестируемого кода.

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

describe("Video", () => {
	it("should return video title", () => expect(video.getTitle()).toBe(TEST_TITLE));
	it("should return video bitrate", () => expect(video.getBitrate()).toBe(TEST_BITRATE));
});

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

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

К компонентным и формализующим BDD тестам уже не может быть применён итеративный подход TDD. Сами тесты могут не быть такими атомарными и реализация, необходимая для их выполнения, не всегда тривиальна.

by 23.11.2015