Читаю книгу Роберта Мартина «Чистый код». Добрался до главы про тестирование. Она хоть и затрагивает тему поверхностно, всё же содержит в себе немало хороших рекомендаций. Ниже те, что я выписал.
Три закона TDD
- Не пишите код продукта, пока не напишете отказной модульный тест.
- Не пишите модульный тест в объёме большем, чем необходимо для отказа. Невозможность компиляции является отказом.
- Не пишите код продукта в объёме большем, чем необходимо для прохождения текущего отказного теста.
Чистота тестов
Тестовый код не менее важен, чем код продукта. Не считайте его «кодом второго сорта». К написанию тестового кода следует относиться вдумчиво, внимательно и отвественно. Тестовый код должен быть таким же чистым как и код продукта.
Какими отличительыми признаками характеризуется чистый тест? Тремя: удобочитаемостью, удобочитаемостью и удобочитаемостью. Вероятно, удобочитаемость в модульных тестах играет ещё более важную роль, чем в коде продукта. Что делает тестовый код удобочитаемым? То же, что делает удобочитаемым любой другой код: ясность, простота и выразительность. В тестовом коде необходимо передать максимум информации минимумом выразительных средств.
Хорошо написанный тест имеет понятную и простую структуру состоящую из трёх частей: построение, операция, проверка. Первая часть строит тестовые данные, вторая часть выполняет с ними операции, а третья часть проверяет, что операция привела к ожидаемым результатам.
Двойной стандарт
Код тестового API подчиняется несколько иным техническим стандартам, чем код продукта. Он также должен быть простым, локаничным и выразительным, но от него не требуется такая эффективность. В конце концов, тестовый код работает в тестовой среде, а не в среде реальной эксплуатации продукта, а эти среды весьма заметно различаются по своим потребностям.
Одна концепция на тест
В тестовой функции должна проверяться только одна концепция, а количество дириктив asserts должно быть минимальным.