Test-Driven Development на практике

[alexinspir]

На пятом этапе мы реализуем методы релизного класса.

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

В тестовом классе обнаружились 3-4 грубых ошибки, которые были исправлены.

Получившиеся классы прикреплены к сообщению.

[alexinspir]

В ходе создания данного руководства я намеренно не исправлял свои ошибки в коде на предыдущих этапах (т.е. находясь на 4-м этапе я не правил код опубликованный на 3, 2 и 1 этапах), за исключением некоторых косметических исправлений.
Сделал я так чтобы показать устойчивость данного подхода к ошибкам.

Что же нам дал TDD, и чем он лучше написания тестов после разработки (и тем более игнорирования модульного тестирования)?
1. Мы заранее составили большую часть контракта релизного класса.
2. Мы составили релизный класс так, чтобы его было удобно тестировать.
3. Тесты стали не только контролировать качество продукта, но и обеспечивать качество продукта.

Чем подход с тестированием лучше подхода без тестирования?
1. Вероятность появления ошибок в конечном продукте падает (перемножение вероятностей появления ошибок в тесте и в релизном классе меньше, либо равно любой из них).
2. Повышение устойчивости к ошибкам при добавлении и/или изменении поведения/функционала релизного класса (предположим, мы хотим добавить что-то, но совершили ошибку, которая повлияла на то поведение/функционал, которое мы не хотели менять - тесты того поведения/функционала скорее всего сразу выявят эту ошибку)

В первом сообщении я упоминал об исключениях в порядке следования этапов (10%, определены на вскидку) - эти исключения связаны с ошибками, которые все равно появляются(например, добавление новых методов в релизный класс на 4-м и 5-м этапах, добавление/изменение тестов на 5-м этапе).

Я далеко не гуру в TDD - применять его активно я стал только сравнительно недавно и среди моих знакомых, с которыми я часто общаюсь/общался, модульное тестирование крайне не в почете.
Многие обосновывали свою пренебрежение к TDD примерно одинаково: TDD обеспечивает только скорость разработки, снижая качество результата; что есть в корне не верно - TDD как раз обеспечивает качество продукта.

Я не профессионал в области составления руководств и как человеку, мне свойственно ошибаться - очень вероятно что я где-либо допустил ошибки или очень плохо изложил материал. Если вы обнаружили что-либо из этого (или вообще что-то чего я не ожидаю), сообщите мне об этом, я постараюсь как можно быстрее исправить недочеты/ошибки.

[alexinspir]

В ходе написания тестов для другой части проекта выявлена ошибка в работе обертки.
Ошибка вызвана некорректной работе методов чтения из буфера.

В качестве задания для всех интересующихся: найти ошибку и написать к ней тесты поведения.

[8Observer8]

Пример разработки программы на языке C по методологии экстремального программирования (с помощью CuTest):

Паказал на простом примере (взятом из readme.txt, из скаченного архива с CuTest): http://programmersforum.ru/showpost....4&postcount=41

Дополнение к предыдущей ссылке: http://programmersforum.ru/showpost....4&postcount=45

Пошаговая инсрукция начала применения CsUnit (для разработки на C#):

http://www.csunit.org/tutorials/tutorial8/index.html


Testing Framework:

http://c2.com/cgi/wiki?TestingFramework