EvilsInterrupt
@EvilsInterrupt
System programming, Reversing Engineering, C++

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

Привет

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

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

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

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

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

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

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

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

Мне хочется, чтобы опытные коллеги которым удалось приучить себя работать по TDD поделились опытом и нашли изъяны в моей практике программирования
  • Вопрос задан
  • 3023 просмотра
Пригласить эксперта
Ответы на вопрос 2
Trrrrr
@Trrrrr
У нас сделанно так:
Проект и тесты в одном солюшене. Проект разбит на кучу либ, и от них екзешники, которые имеют не очень много функционала. Тестируем только либы.
Компиляция почти не замедляется, правда используем гуглтест, может с бустом быть медленнее.

Что бы эфективно использовать ТДД необходимо заранее продумывать интерфейсы, как только продумал интерфейс, уже можно писать.
Хотя бы так
class Summator
{
public:
 int Sum(int a, int b) { throw std::expcetion("not implemented");}
}

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


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

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

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы