CppUnit и размышнения по теме
Наконец-то "продавил" использовать на проекте CppUnit. Результатами очень доволен. Два дня на изучение и компиляцию самого фреймворка (из них один день на борьбу с проблемой памяти на границе dll, очень для меня неожиданно оказалось - сказывается отсутствие опыта разработки под винду) - и можно легко писать тесты.
Самое классное при таком подходе - это исправление ошибки. Написал тест, который обнаружил проблему, нашел саму проблему, написал ее исправление, запустил уже написанный тест и тут же увидел, решил ты проблему или нет. Никакого тебе рутинного повторения теста вручную!
Второе классное - это то, что чего-нибудь сделав с проектом, в один клик можно убедиться, что в покрытой тестами части ничего не сломалось.
И несмотря на то, что преимущества такого подхода очевидны (world best practice, однако), убедить в этом руководство и заказчика - весьма нетривиальная задача. Корень зла, конечно, в оплате "time plus material", при которой за все платит заказчик, а сокращение времени разработки означает меньше полученных от заказчика денег...
Что самое интересное - на одном из предыдущих проектов система автоматизированных тестов успешно была продана заказчику, и показала она себя отлично - множество ошибок класса "фиг найдешь вручную" было выявлено лишь благодаря этой системе. Правда, вместо стандартного фреймворка использовалась дипломная работа одного из молодых разработчиков. Для дипломной работы разработка тестового фреймворка со своим собственным языком тестовых скриптов, конечно, это очень хорошо, но вот с точки зрения стабильности, юзабилити и функциональности - увы, ни в какое сравнение не идет с тем же CppUnit.
И еще - в недалеком прошлом в небольшом и не получившем продолжения проекте я добавлял в pyUnit возможность сохранять результаты запуска тестов в базу данных. Так вот, если посмотреть на одинаковый по функциональности фреймворк, написанный на С++ и на Python, то очень хорошо будет заметно, какой из языков более элегантный, простой и мощный :)
Самое классное при таком подходе - это исправление ошибки. Написал тест, который обнаружил проблему, нашел саму проблему, написал ее исправление, запустил уже написанный тест и тут же увидел, решил ты проблему или нет. Никакого тебе рутинного повторения теста вручную!
Второе классное - это то, что чего-нибудь сделав с проектом, в один клик можно убедиться, что в покрытой тестами части ничего не сломалось.
И несмотря на то, что преимущества такого подхода очевидны (world best practice, однако), убедить в этом руководство и заказчика - весьма нетривиальная задача. Корень зла, конечно, в оплате "time plus material", при которой за все платит заказчик, а сокращение времени разработки означает меньше полученных от заказчика денег...
Что самое интересное - на одном из предыдущих проектов система автоматизированных тестов успешно была продана заказчику, и показала она себя отлично - множество ошибок класса "фиг найдешь вручную" было выявлено лишь благодаря этой системе. Правда, вместо стандартного фреймворка использовалась дипломная работа одного из молодых разработчиков. Для дипломной работы разработка тестового фреймворка со своим собственным языком тестовых скриптов, конечно, это очень хорошо, но вот с точки зрения стабильности, юзабилити и функциональности - увы, ни в какое сравнение не идет с тем же CppUnit.
И еще - в недалеком прошлом в небольшом и не получившем продолжения проекте я добавлял в pyUnit возможность сохранять результаты запуска тестов в базу данных. Так вот, если посмотреть на одинаковый по функциональности фреймворк, написанный на С++ и на Python, то очень хорошо будет заметно, какой из языков более элегантный, простой и мощный :)