C ++ и правильный TDD

Question

Привет! Недавно я пытался разработать небольшой проект в C#, и в течение всего проекта наша команда использовала технику Test-Driven-Development (TDD) (xunit, moq).

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

Сразу после этого я попытался использовать TDD в паре с C++ (я использовал библиотеки Google Test и Google Mock), и я не знаю почему, но на самом деле я думаю, что TDD здесь был шагом назад в Условия быстрой разработки приложений.

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

И, ну, я, очевидно, не могу спросить что-то вроде "что я сделал не так?" или «что не так в моем подходе?», потому что я не знаю, что описать. Но если есть люди, которые привыкли к TDD в C++ (и, вероятно, C#) тоже, не могли бы вы посоветовать мне, как это сделать правильно.

Рекомендации по структуре, подходы к архитектуре, советы по простому кодированию - если вы знакомы с TDD & C++, пожалуйста, ответьте.

Answer 1

Я думаю, что TDD намного сложнее сделать в C ++, чем в C #. Отсутствие рефлексии и общее (и часто вполне оправданное) нежелание полагаться на динамический полиморфизм (интерфейсы и наследственность) по сравнению со статическим полиморфизмом затрудняет моделирование многих классов.

Существуют очень умные фреймворки для модульных тестов для C ++, но в них так умно в основном то, что они пытаются обойти языковые ограничения.

TDD лучше всего работает на динамических языках. Это отличный способ работать в Python. Это выполнимо в C # (который не является динамическим, но имеет широкие возможности отражения)

В C ++ это часто проблематично. Это не значит, что это не может или не должно быть сделано, но когда вы это сделаете, ожидайте, что вам придется работать немного усерднее. А иногда вам может быть лучше использовать другой подход полностью.

Answer 2

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

На этом этапе моей первой реакцией на проблему такого рода является пересмотр моих первоначальных предположений о проблеме. Я делаю это более сложным, чем это должно быть? Пытаюсь ли я написать тесты, чтобы прийти к дизайну, о котором я уже решил, вместо того, чтобы позволить тестам руководить проектом? Это просто забавная проблема, и я должен признать, что в этом случае типичный подход TDD не сработает?

Для интересного обсуждения этого вы можете посмотреть это сообщение в блоге от дяди Боба Мартина, где он рассказывает о попытке Рона Джеффриса создать Решатель Судоку с использованием TDD , и это на самом деле не работает. Теперь, поскольку эта попытка не привела к хорошему решению, это не означает, что TDD бесполезен, это просто означает, что решаемая проблема является более сложной и не подходит для возникающего подхода проектирования TDD.

Answer 3

Попробуйте самое легкое - CxxTest .

Answer 4

Я нахожу разработку, управляемую тестами, очень трудной, чтобы все время делать правильно; иногда тесты просто текут, иногда требуется небольшой скачок. Чтобы сохранить скорость, я часто отхожу от подхода TDD. Для меня это не проблема, так как я поддерживаю полный набор модульных тестов для всего кода, который я «завершил» (позволяя расслабиться при кодировании новых битов и рефакторинге).