Тесты вперед?

Многие меня спрашивают: "Не жалко тебе тратить время на написание тестов?". Могу ответить коротко: "Нет".

Почему я могу позволить тебе половину своего рабочего времени посвятить тестированию? Неужели не лучше сразу писать код? Подождите! Не сразу, конечно. Надо накидать архитектуру. Должны же мы понимать, как и что мы хотим сделать. На сколько детально надо проработать архитектуру? Опишем основные "слои" системы и их взаимодействия? Или будем разбивать эти слои на объекты и решать, как этим объектам себя вести?

Представим себе, что мы сидим перед чистым листом бумаги и только что созданным проектом без единой строчки кода. У меня есть свои мысли о работе системы. У моего коллеги практически такие же, но он задумал использовать новую технологию и пытается подстроить требования к системе под ее возможности. У нашего ведущего программиста ещё более глобальные идеи о грядущей работе. Как нам договориться и составить общее представление?

Мы будем используем понятные нам всем термины. Общий язык, на котором мы сможем договориться. К примеру - UML.

Создадим консольный калькулятор?

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

Я говорю: "Я вижу объект Calculator. Ему на вход передается строка. Он может совершать операции над операндами. Операнды поступают в виде массива строк, которые ввел пользователь."

Мне возражают: "Как он распарсивать будет? А давайте ему добавим метод Parse?..." При этом на доске уже начали появляться первый диаграммы взаимодействия. Работа идёт полным ходом...

Что мы делаем? Договариваемся о том, какой будет код? Кое будет API? А где код? Как его увидеть?

Я вижу его по-своему. Эти объекты и их поля, как они взаимодействует. В моей голове уже все в движении, сообщения передаются, исключения перехватываются, работа идёт полным ходом. Мои коллеги сидят и вкушают триумф разбора строки пользователя. Кто-то уже начал думать над форматом выдачи результата. О том, как лучше пользователю это показать, что написать при делении на ноль.

Как мне передать мои "ощущения" кода коллегам? Нужно показать им этот код! Тогда уже начнётся более предметный разговор. После разговоров и рисования диаграмм мы расселись по местам и начали кодировать.

Кто-то скажет: "Да нет, это же не эстетично вызывать Calculate с тремя параметрами. Давайте создадим отдельную функцию Add, которая будет принимать два операнда?"

Зачем мы рисовали диаграммы, где все уже расписано и так красиво выглядит? После первой строчки кода они потеряли свою актуальность.

Альтернативный подход.

Забудем на время все диаграммы со стрелочками и условными обозначениями. Сейчас нам пока не о чем уславливаться. Ещё ничего нет. Давай синхронизируем наше "видение" проблемы.

Начнём с теста. Мы с коллегой садимся за его компьютер. Я беру себе клавиатуру и начинаю проговаривать, что я "вижу".

Я говорю: "Хочу, чтобы был объект Calculator и он принимал на вход 3 параметра".

Мой коллега (К) отвечает: "Покажи мне код, который ты хотел бы использовать"

[Fact]
public void AddTest()
{
    var calculator = new Calculator();
    calculator.Calculate(?
}

(Я): "А откуда возьмутся аргументы?"

(К): "Мне кажется их надо передать в конструктор".

Я продолжаю печатать.

[Fact]
public void AddTest()
{
    string[] args = new {"1", "+", "2"};
    var calculator = new Calculator(args);
    calculator.Calculate(?
}

(К): "Я бы предпочел вызвать конкретную операцию. Например для сложения Add"

(Я): "Я поймал себя на той же мысли =)..."

[Fact]
public void AddTest()
{
    string[] args = new {"1", "+", "2"};
    var calculator = new Calculator(args);
    calculator.Add();
}

(К): "А почему именно Add? Может я передал знак вычитания. Вообще говоря я вижу, что твой класс Calculator имеет определенное поведение, но не могу понять где его состояние?"

(Я): "Т.е. нет смысла создавать его экземпляр, когда нам надо складывать?"

(К): "Я вижу это так" (берет себе клавиатуру)

[Fact]
public void AddTest()
{
    string[] args = new {"1", "+", "2"};
    Calculator.Add(args);
}

(Я): (косо глядя на напарника) "Передвать аргументы в Add? Ты же не хочешь сказать, что каждая функция калькулятора, будет разбирать этот массив строк и решать, что с этим делать дальше? Вообще почему ты решил, что разбираться с вводом пользователя - это работа для калькулятора?"

(К): (ударил себя по лбу) "Нам нужен парсер этих аргументов!"

(Я): "Покажи мне код!"

[Fact]
public void AddTest()
{
    string[] args = new {"1", "+", "2"};
    var parser = new ArgumentParser(args);
    double result = Calculator.Add(parser.FirstOperand, parser.SecondOperand);
    Assert.Equal(3, result);
}

И так далее...

Обратите внимание, что все программирование велось в сборке UnitTests и класс Calculator создан не был. Мы просто придумывали каким мы хотим видеть его API.

Результаты:

1. Приложение работает на "красивом" API
2. Дизайн системы намного лучше, чем если бы мы вылили свое воображение на бумагу, а уже потом, придерживаясь его, начали программировать.
3. Код получается изначально тестабильным (testable).

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

Обсуждение этой темы на blogs.gotdotnet.ru