C++ и надлежащий TDD
Привет! Я недавно попытался разработать проект маленького размера в C# и во время целого проекта наша команда использовала Разработку через тестирование (TDD) техника (xunit, moq).
Я действительно думаю, что это было потрясающим, потому что (при соединении с C#) этот подход позволил ослабляться при кодировании, ослабляться при проектировании и ослабляться при рефакторинге. Я подозреваю что все это TDD- материал на самом деле упрощает процесс кодирования, и, ну, в общем, он позволил (в конечном счете для меня) получать тот же результат с меньшим количеством работы клеток головного мозга.
Право после этого я пытался использовать TDD соединенный с C++ (Я использовал Google Test и Google Mock библиотеки), и, я не знаю, почему, но я на самом деле думаю, что TDD здесь был шагом назад с точки зрения быстрой разработки приложений.
У меня было несколько моментов, когда я должен был провести огромное количество времени, думающее о моих тестах, создав надлежащие насмешки, восстановив их и ругая мой монитор.
И, ну, в общем, я, очевидно, не могу спросить что-то как, "что я сделал неправильно?" или, "что было неправильным в моем подходе?", потому что я не знаю, что описать. Но если существуют какие-либо люди, которые привыкли к TDD в C++ (и, вероятно C#) также, могли Вы советовать мне, как сделать это правильно.
Рекомендации платформы, подходы архитектуры, простые советы кодирования - если Вы испытаны в TDD & C++, ответьте.
4 ответа
Я думаю, что TDD намного сложнее реализовать на C ++, чем на C #. Отсутствие отражения и обычное (и часто вполне оправданное) нежелание полагаться на динамический полиморфизм (интерфейсы и наследование) по сравнению со статическим полиморфизмом действительно затрудняют имитацию многих классов.
Есть несколько чрезвычайно умных фреймворков для модульного тестирования для C ++, но самое умное в них состоит в том, что они пытаются обойти языковые ограничения.
TDD лучше всего работает с динамическими языками. Это отличный способ работать с Python. Это выполнимо в C # (который не является динамическим, но имеет широкие возможности отражения)
В C ++ это часто проблематично. Это не значит, что этого нельзя или не следует делать, но когда вы это делаете, ожидайте, что придется работать над этим немного усерднее. И иногда вам может быть лучше использовать совершенно другой подход.
TDD - это то, что требует некоторой практики, независимо от платформы. Некоторые люди не понимают, что характер проблемы, которую вы пытаетесь решить, может сильно повлиять на то, насколько легко вы сможете применить TDD к решению. В прошлом у меня были проблемы, когда я знал, к какому решению хочу двигаться, но было очень трудно понять, как разбить проблему на части так, чтобы она соответствовала модели TDD. Сейчас есть несколько причин, по которым это может произойти, и невозможно сказать, каков "правильный" способ справиться с этой ситуацией.
На данный момент моей первой реакцией на столкновение с подобной проблемой является пересмотр моих первоначальных предположений о проблеме. Не усложняю ли я ее больше, чем нужно? Не пытаюсь ли я написать тесты, чтобы прийти к уже принятому решению, вместо того, чтобы позволить тестам направлять проектирование? Может быть, это просто странная проблема, и мне нужно принять тот факт, что типичный подход TDD в данном случае не сработает?
Для интересного обсуждения этого вопроса вы можете посмотреть эту запись в блоге дяди Боба Мартина, где он рассказывает о попытке Рона Джеффриса создать решатель судоку с помощью TDD, и это действительно не сработало. То, что эта попытка не привела к хорошему решению, не означает, что TDD бесполезен, это просто означает, что решаемая проблема сложнее и не поддается подходу TDD, основанному на эмерджентном проектировании.
Я нахожу, что разработку, управляемую тестами, очень трудно постоянно делать правильно; иногда тесты просто текут, иногда требуется небольшой скачок. Чтобы не терять скорость, я часто отхожу от подхода TDD. Для меня это не проблема, поскольку я поддерживаю полный набор модульных тестов для всего кода, который я "завершил" (позволяя себе расслабиться во время написания новых частей и рефакторинга).