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

[vak]

Нас всех учили понемногу, чему-нибудь и как-нибудь. В моё время, в середине 80-х обучение программированию сводилось к изложению синтаксиса языка и написанию коротких изолированных задачек. На первом курсе нам давали Алгол и Бейсик, на втором Фортран и Паскаль, на третьем ассемблер (тогда он назывался автокод) и снова Фортран, на четвёртом почему-то опять Фортран, с самого начала.

Собственно программированию не учили совсем. Я имею в виду, как инженерному искусству. Стиль, методы организации программного проекта, автоматическую сборку, управление версиями и прочие премудрости приходилось осваивать самостоятельно. Ковырялся в исходниках Юникса и компилятора PCC, подсматривал у старших товарищей в курчатнике, рылся в ленточках Usenix. Толковых книг не было совсем, а преподаватели с реальным практическим опытом не встречались в природе.

С тех пор много воды утекло, и сейчас есть несколько книжек, учащих реальным приёмам программирования. Вот одна из них: "Modern C++ Programming with Test-Driven Development".



В книжке предлагается метод разработки, основанный на написании небольших тестов - сначала, до собственно функционального кода. Суть метода можно понять из статьи википедии "Разработка через тестирование". Русское название звучит несколько неоднозначно, и я предпочитаю называть метод оригинальным термином TDD.



Кроме TDD есть и другие подходы: BDD, TSD и прочие. Но все большие проекты из моего опыта используют методику "непрерывного" тестирования. Без этого разработка больших продуктов вообще невозможна, ведь внося любое изменение программист нарушает поведение системы. Без набора тестов с хорошим покрытием невозможно определить, насколько допустимо это нарушение.

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

В качестве заготовки я приготовил два репозитория (на Гитхабе и на Битбакете) с одним и тем же примером на Си++: вычислением чисел Фибоначчи.

• https://github.com/sergev/Catch-Actions-Demo
• https://bitbucket.org/serge-vakulenko/catch-pipelines-demo

Тестируемая функция - вычисление чисел Фибоначчи методом конечной рекурсии: demo.cpp

Набор тестов к ней: test_demo.cpp

Запуск тестов выглядит так:



После каждого коммита заходим на вкладку Actions (на Гитхабе) или Pipelines (на Битбакете) и смотрим результаты автоматического тестирования.

Comments

[vit_r]

Не знаю, почему вас не учили. Я писал диплом по методике Джексона.

[gonchar]

Любопытство - тот тезис, который я ниже напишу, он - банальность, чепуха, что-то иное?

Тезис.
В программировании как таковом нет ничего сложного, чему человек уровня 10 классов (если не меньше) не мог бы научиться за несколько месяцев. После этого он сможет без проблем писать любые программы.

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

[sab123]

Идея о писании тестов до кода неправильная. До реализации есть смысл писать примеры использования. Но это совсем-совсем не то что тесты. Примеры должны быть маленькими, а тесты - наоборот, детальными и залазящими в каждый закоулок. Если писать тесты до реализации, то это большое количество выбрасываемой на ветер работы (потому что их та кили иначе придется исправлять по релузьтатам реализации). Поэтому я подозреваю, что у таких авторов очень неправильнео понимание, что такое тесты.