TDD и формализация требований 20.12.2015

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

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

Рассмотрим простой пример. Для обозначения сигнатур методов я буду использовать синтаксис Typescript. Допустим, нам необходимо реализовать класс PostList, реализующий коллекцию статей. Статья Post определяется ее содержимым, датой добавления, рейтингом полезности, а также, языком локализации. В свою очередь, коллекция должна уметь возвращать список всех статей, отсортированных по дате добавления (например, методом getPosts():Post[]), а также список статей на определенном языке и отсортированный по пользовательскому рейтингу (getPostsByLocalization(lang:Lang):Post[]). В качестве исходных данных при создании коллекции мы используем, например, JSON с соответствующими данными о статьях. Тогда в терминах тестов, требования к классу будут выглядеть примерно так:

describe("PostList", () => {
	describe("getPosts", () => {
		it("возвращает список всех статей, отсортированный по дате добавления", () => {});
	});
	describe("getPostsByLocalization", () => {
		it("возвращает только статьи, язык которых соответствует переданному в качестве параметра", () => {});
		it("возвращает список, отсортированный по рейтингу пользователя", () => {});
	});
});

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

by 20.12.2015