Дизайн для тестируемости в C ++

Question

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

Я привык к кодированию интерфейсов, внедрению зависимостей,инверсия управляющих структур и макетов объектов.Поскольку в C # есть много разных языковых возможностей, я не уверен, сколько шаблонов все еще следует применять.Я также полагаю, что уникальные функции / ограничения C ++ могут быть полезны для различных стратегий тестирования.

Я смотрел на основы модульного тестирования, и мне нравится Google Test , но также важно написать свой свежийкод, который должен быть максимально тестируемым

Какие-нибудь книги или статьи, которые более подробно рассматриваются в этой теме? Рекомендации по дополнительным фреймворкам / библиотекам

Спасибо

Answer 1

Я сейчас в точно такой же ситуации.Исходя из C # фона, теперь я пишу новые (и расширяю старые) приложения C ++.

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

Проблема, как вы, кажется, подчеркнули, заключается в том, что, возможно, лучшая практика в C # - не лучший способ в C ++.После долгих исследований, некоторых моих собственных вопросов о переполнении стека и некоторых прототипов я получил архитектуру C ++, которая во многих отношениях отражает то, что, по моему мнению, лучше всего работает в C #.

Вот основные принципы, которые я использую:

• Внедрение зависимостей

  Конструкторы для наших классов принимают интерфейсы для зависимостей, которые мы могли бы захотеть смоделироватьв качестве параметров.В некоторых случаях это означало написание оболочек для зависимостей, таких как boost :: filesystem, например, которая в основном реализована в шаблонных заголовках.На мой взгляд, стоит небольшого усилия, так как оно более свободно связывает нас с библиотеками, которые мы можем изменить или поменять местами, и это позволяет нам проводить модульное тестирование с фиктивными реализациями.

• Тестируйте, как вы идете!

  Это само собой разумеется, но написание тестов во время написания класса позволяет проверить работоспособность вашего проекта в отношении тестируемости.Меня не волнует, что вы сначала тестируете, делаете TDD, или как вы там это называете, моя философия - просто написать ваши тесты, прежде чем вы начнете использовать класс в своей кодовой базе.

• Google Test в качестве основы нашего модульного тестирования

  До сих пор я использовал Cxxtest (устаревшие приложения) и Google Test.Google Test предоставляет множество гибких параметров во время выполнения, чтобы определить, какой набор тестов вы выполняете.Мы разделили наше соглашение об именах классов на UnitTest_xxxx и IntegrationTest_xxxx.Затем в командной строке я могу сказать gtest запускать тесты только с одним именем, другим или обоими.Тогда мой сервер сборки может выполнять долгосрочные тесты по всему набору тестов ночью, но модульные тесты при каждой регистрации. Cxxtest может делать то же самое, но с большей работой, и, как правило, неуклюже по многим причинам.

• Google Mock для фиктивных объектов во время тестирования

  Очевидным преимуществом внедрения зависимостей является использование фиктивных объектов во время тестирования.Можно просто написать фальшивые реализации для каждого интерфейса, но Google Mock позволяет быстро раскрутить фальшивые объекты и предоставляет типичные проверки, которые можно ожидать от хороших фреймворков .NET, таких как Moq или RhinoMock.

Answer 2

Я использовал CPP Unit , который является портом JUnit.Он очень прост в использовании и обеспечивает вывод в формате XML, и это здорово.Что касается его использования, вы можете проверить кулинарную книгу здесь.

Answer 3

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

С моей точки зрения, наиболее важной техникой разработки для обеспечения качества кода на C ++ является использование объектно-ориентированных методов , таких как модульность, принцип Open-Closed, самодокументирование, разделение команд-запросов и т. Д. .

В частности, два метода, которые я считаю необходимыми: Дизайн по контракту (см. Вопросы Каков наилучший способ реализации проверки утверждений в C ++? и Дизайн по Контракт в C ++? ) и Unit Testing (см. Связанные вопросы 1 , 2 , 3 ). Для них обоих у вас есть разумные инструменты в C ++, как показывают связанные вопросы.

Answer 4

Я могу порекомендовать UnitTest ++ и AMOP для разработки, основанной на тестировании. Оба очень просты в настройке и очень мощные. Если вам не нужны все функции в Google Test, это хороший выбор.

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