Как эффективно юнит-тестить в C++ проектах?

Question

[Дмитрий]

Привет

Мне хочется улучшить качество моей работы по TDD.

Что пояснить, что же мне не нравится, опишу, как устроена жизнь в данный момент.

Основные инструменты это MSVS 2010/2012 и Boost.Test. Проект моей тулзы имеет два solution-файла: один для основного кода и второй для юнит-тестов. Другими словами сейчас мои юнит-тесты по факту похожи на регрессионные.

Также следует отметить, что у меня все собирается с precompiled headers этот нюанс нужно учитывать при чтении текста ниже.

Первая причина почему так получилось: потому что юнит-тесты используя основной код компилируются долго и как вывод выполняются дольше, тогда и принял решение выделить тесты в отдельную часть solution прекрасно понимая что это не TDD когда надо сначала тест, а потом основной код.

Вторая причина такой ситуации это недостаточно быстрое переключение между основным кодом и тестовым.

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

Буквально недавно получил разработки на Java и мне очень понравилось, как в NetBeans решается все эти три проблемы. С помощью горячих клавиш переключение в тестовый код; выполнение всего набора тестов или того модуля, который открыт.

Мне хочется, чтобы опытные коллеги которым удалось приучить себя работать по TDD поделились опытом и нашли изъяны в моей практике программирования

Answer 1

[Trrrrr]

У нас сделанно так:
Проект и тесты в одном солюшене. Проект разбит на кучу либ, и от них екзешники, которые имеют не очень много функционала. Тестируем только либы.
Компиляция почти не замедляется, правда используем гуглтест, может с бустом быть медленнее.

Что бы эфективно использовать ТДД необходимо заранее продумывать интерфейсы, как только продумал интерфейс, уже можно писать.
Хотя бы так

class Summator
{
public:
 int Sum(int a, int b) { throw std::expcetion("not implemented");}
}

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

Comments

[Дмитрий]

т.е. у Вас как то так:
lib1.vcxproj
lib1test.vcxproj
lib2.vcxproj
lib2test.vcxproj

?

[Trrrrr]

по разному, на предыдущем месте работы было так. Сейчас только один тест, но мы не ставим задачу покрыть все. Задача - покрыть основные алгоритмы. Т.е. обьем тестов небольшой.

[Дмитрий]

Насколько быстро Вы "Летаете" между основным кодом и тестовым? Как быстро переключаетесь? Как быстро запускается на выполнение юнит-тест и как быстро он выполняется? Быстро ли пишутся новые юнит-тесты? Возникает ли мысль отложить написание юнит-теста на потом?

[Trrrrr]

Все зависит от человека. Я в данный момент лид проекта. Вот если лень человеку юниттест писать, то он его даже если и напишет но толку от него не будет совсем. У нас в проекте очень много мат. алгоритмов поэтому их тестирование вполне тривиальное. И большинство тестов работает менее секунды. И что значит летаете над основным кодом? Туда сюда не более 1-2 раза. Написал код, написал тест(или наоборот;)) запустил, убедился что работает. Дальше запускает билдсервер, если что не так упадет еще там.

[Дмитрий]

Тогда сдается мне, что Вы не TDD используете

[Trrrrr]

А я и не утверждаю что идеально ТДД. У нас нету цель делать полное покрытие всех классов. Только тех, которые решают разные мат задачи. А в этом случае все довольно тривиально, так как заумных связей нет. Есть просто данные на входе и на выходе.

[Trrrrr]

Т.е. объемы тестируемого кода не велики поэтмоу ваших проблем нет. А так да в С++ это не настолько удобно как возможно хотелось бы.

[Дмитрий]

@Trrrrr У меня другая цель: "летать" между основным кодом и тестовым. Об этом писал в моем самом первом посте. Другими словами мне хочется оооочень быстро переключаться из основного в тестовый, чтобы эти переходы были почти не заметны! Пока мне этого не удается. Моя цель придти к TDD. Т.е. сначала тест, потом основной код, потом проверка "написано или еще не работает?". Сейчас же у меня не так. О том как у меня опять таки к моему первому посту!

[Trrrrr]

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

[Дмитрий]

@Trrrrr Вы на хабре как read-only , как с Вами можно связаться?

[Trrrrr]

@EvilsInterrupt den_sumy88 скайп, пишите :) буду рад пообщаться.

[Дмитрий]

@Trrrrr Спасибо, я Вам в скайп кусок кода послал ;)

Answer 2

[Орехов Алексей]

Другими словами сейчас мои юнит-тесты по факту похожи на регрессионные

юнит-тесты - тесты, проверяющие конкретный, небольшой модуль приложения
regression тесты - призваны проверять работоспособность приложения после внесенных изменений.

То есть это не связные понятия. Регресс можно выполнять и с помощью юнит-тестов и без них.

По теме: не нужно писать тесты ради тестов. Эта ересь (TDD) пошла из пораженных языков (JavaScript, Python, PHP) на который в принципе невозможно писать крупные проекты.
Сложность очень быстро увеличивается. Работу компилятора выполняет программист.
И чтобы снизить сложность, придумали TDD, которые проверяют твой код.

Comments

[Дмитрий]

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