Использование Google test framework для тестирования кода Visual C++ (Visual Studio 2012)

После прочтения книг по TDD и внедрения этой методики в мои проекты на C#, я решил разобраться как с этим дела обстоят в Visual С++. Тем более, что для тестирования математических расчетов я пользовался ручкой и бумагой, что было очень утомительно и трудозатратно. Посмотрев материалы по тестированию кода на MSDN, мой выбор пал на Google test framework из-за нескольких причин:  

• простота установки;
• интуитивно понятный язык написания тестов.

Так как для проекта мне нужно было тестировать только математические вычисления (не нужно было делать mock объекты и т.д.) функционал Google test меня полностью устраивал. Итак, установка:

• качаем последнюю версию framework-ка;

компилируем google test в статическую библиотеку, для этого добавляем в наше решение с тестируемым проектом новый проект:

Unit testing and Dependency Injection (DI) pattern.

Как известно использование сильно связанных классов это плохо, так как попытка внести изменения в один класс, неизбежно повлекут за собой, целую цепочку изменений в других классах. Особенно это проявляется при поддержке больших систем, состоящих из огромного числа классов. Кроме того, такой подход увеличивает сложность тестирования, так как один класс невозможно протестировать отдельно от другого. Для уменьшения связанности классов необходимо программировать на уровне интерфейсов, а не на уровне реализаций, т.е. всю логику, которая гипотетически может измениться необходимо, по возможности,  выносить в интерфейс. Затем, при создании  класса, в его конструктор можно передать объект, реализующий необходимый интерфейс и им инициализировать объект внутри класса (пример). Использование такого подхода описывает паттерн Dependency Injection.  Многие проблемы, возникающие при развитии  системы, могут быть решены,  если при программировании логики работы стараться придерживаться принципов проектирования классов (S.O.L.I.D).  При переходе к программированию на уровне интерфейсов  создание объектов может сильно усложниться, так как каждый раз при создании нового объекта нам необходимо будет настраивать  его зависимости.  Для простых объектов это может показаться не очень сложным, однако при усложнении системы простая инициализация объекта будет вести за собой целую цепочку вызовов разрешений зависимостей, и это будет необходимо делать при каждой инициализации объекта.  Для решения этой проблемы существует множество DI frameworks, которые при правильной настройке позволяют легко инициализировать объекты вместе с их зависимостями. В своей работе я использовал два framework-а: Unity и Ninject. Скажу честно, какой-то принципиальной разницы между ними не нашел, кроме того, что Ninject интегрируется с MVC «из коробки» и еще мелких различий, поэтому тут опишу только Ninject.