Хтось робить "справжній" TDD з Visual-C ++, і якщо так, то як це робити? [зачинено]

Тестова розробка передбачає написання тесту перед кодом та наступний певний цикл :

• Тест з написання
• Перевірка тесту (запустіть)
• Напишіть виробничий код
• Перевірка тесту (запустіть)
• Очистити виробничий код
• Перевірка тесту (виконання)

Що стосується мене, це можливо лише в тому випадку, якщо ваше рішення для розробки дозволяє дуже швидко перемикатися між виробничим і тестовим кодом і надзвичайно швидко виконати тест для певної частини виробничого коду.

Тепер, хоча існує багато фреймворків тестування модулів для C ++ (я використовую Bost.Test atm.), Схоже, насправді не існує пристойного (для рідного C ++ ) рішення Visual Studio (Plugin), яке робить TDD цикл можна носити незалежно від використовуваної рамки.

"Bearable" означає, що це дія одним клацанням миші для запуску тесту для певного файлу cpp без необхідності вручну встановлювати окремий проект тестування тощо. "Bearable" також означає, що простий тест починається (пов'язує!) І працює дуже швидко .

Отже, які інструменти (плагіни) та методи існують там, що роблять цикл TDD можливим для власного розвитку C ++ за допомогою Visual Studio?

Примітка: я добре вживаю безкоштовні або "комерційні" інструменти.

Будь ласка : Немає рамкових рекомендацій. (Якщо рамка не має спеціального плагіна Visual Studio і ви хочете порекомендувати плагін.)

Редагування Примітка : На сьогодні відповіді містять посилання про те, як інтегрувати блок тестування модулів у Visual Studio. Ресурси більш-менш описують, як змусити структуру UT складати та запускати свої перші тести. Це НЕ то , що це питання о. Я вважаю, що дійсно продуктивно працювати, маючи Unit Tests в ручному режимі (!), Окремий vcproj від ваших виробничих класів додасть стільки накладних витрат, що TDD "неможливо". Наскільки мені відомо, ви не додаєте зайвих "проектів" до Java або C #, щоб увімкнути Unit Tests і TDD, і це не є вагомою причиною. Це повинно бути можливо, за допомогою потрібних інструментів C ++, але здається, що (це питання про те), що інструментів для TDD / C ++ / VS дуже мало.

Гулячи навколо, я знайшов один інструмент, VisualAssert , який, здається, спрямований у правильному напрямку. Однак, afaiks, схоже, він не знайшов широкого застосування (порівняно з CppUnit, Boost.Test тощо).

Редагувати: Я хотів би додати коментар до контексту цього питання. Я думаю, що це добре підсумовує викладення (частину) проблеми: (коментар Біллі ONeal )

Visual Studio не використовує "сценарії побудови", які можна редагувати користувачем. Один проект виробляє один двійковий. Більше того, у Java є властивість, що Java ніколи не будує повного бінарного файлу - бінарний файл, який ви будуєте, - це лише ZIP-файл файлів класу. Тому можна скласти окремо, тоді JAR разом вручну (використовуючи, наприклад, 7z). C ++ і C # насправді пов'язують свої двійкові файли, тому загалом кажучи, ви не можете написати такий сценарій. Найближче до вас може скласти все окремо, а потім зробити два зв’язування (одне для виробництва, а одне для тестування).

Я написав 5-частинну серію блогу про те, як робити TDD з C ++ та Visual Studio: частина 1 , частина 2 , частина 3 , частина 4 , частина 5 .

Я не впевнений, чому ви говорите, що ви не робите зайвих проектів в C #, щоб робити TDD, тому що це я завжди робив з NUnit, і це здається типовим для інших людей, які також роблять з NUnit. Причина проста: завжди тримайте код тесту окремо від виробничого коду. Для C ++ з Visual Studio це означає окремі проекти, як і для C # і NUnit. З того, що я знаю про світ Java, це теж є загальним.

Очевидно, у кожного є різні уявлення про те, що "терпимо" для ведення TDD. Я практикую метод, який я викладаю у своєму дописі в блозі протягом суворих років, і вважаю це дуже терплячим. C ++ - це мова, що складається на компіляції, і компілювання матеріалів може бути повільним, коли система, що перевіряється, сильно поєднана. Просто немає жодного відходу від цього без рефакторингу на більш вільно поєднаний дизайн.

Моя "дія одним натисканням кнопки" - "Збірка рішення". Якщо ця будівля надто велика, ви завжди можете вивантажувати нерелевантні проекти під час роботи, а потім Build Solution створюватиме лише мінімальний набір проектів, необхідних для оновлення в результаті змін.

Зрозуміло, що характер компіляції часу C ++ робить це забирати трохи більше часу в кожному циклі процесу TDD, ніж це було для NUnit та C #, але впевненість, яку я отримую від мого добре перевіреного коду C ++, того варта. Інакше я буду витрачати набагато більше часу на відладчику. Я б застеріг бути щадним у використанні gmock, оскільки це може суттєво додати час перевірки компіляції. Я поки що в основному отримував легкі "підроблені" предмети і рідко потребував повноцінного функціоналу знущань. Смішні рамки для C ++ базуються на шаблонах, і це може значно збільшити час компіляції, тому їх слід зарезервувати там, де вам справді потрібен макет, і підробка просто не зробить.

Я розглядав можливість створення майстра тестового проекту Boost.Test для автоматизації деякого характеру пластини котла для створення тестового проекту для виробничого коду, але після того, як ви зробите це в кілька разів, це дійсно не так складно зробити вручну.

Що стосується рішень з багатьма (150?) Проектами, є й способи впоратися з цим. Одне з очевидних - знайти групи пов'язаних проектів і зв'язати їх разом і почати використовувати їх / публікувати їх як одиницю. Якщо вам дійсно потрібно відновити / доторкнутися до всіх 150 проектів для невеликих змін, які ви вносите під час циклу TDD, ваш код все одно настільки сильно зв'язаний, що одиничні тести, ймовірно, не принесуть великої різниці.

Переглядаючи посилання IDE netbeans, я виявляю, що цукерка має те, що аналізує вихідний тест і показує невеликий тестовий рядок у вікні із зеленим або червоним символом поруч із ним, що я думав, що пропущу, що прийшов з NUnit, але насправді не сумував. Мені здалося, що для збірки більш корисним є просто провал, і тоді я міг двічі клацнути у вікні помилок, щоб розмістити курсор у місці невдалого твердження.

Я не використовую Visual-C ++, але я виконую TDD з C ++, використовуючи googletest та googlemock, з QtCreator як IDE. Роки тому в мене було подібне налаштування з Visual-C ++, але я використовував інший блок тестування.

Що мені здалося корисним - це розділити проект на кілька підпроектів.

1. Статична або динамічна бібліотека, яка містить 99% фактичного вихідного коду проекту.
2. Проект, який складається здебільшого з основного () методу для запуску звичайної програми.
3. Тестовий проект, який містить main () для запуску моєї тестової рамки та безліч файлів, що містять тести та макети об’єктів.

За допомогою цієї установки мій IDE піклується про додавання файлів до різних проектів, і якщо правильно визначаються залежності, я можу запустити всі мої тести з частковою перебудовою. У мене навіть є налаштування для запуску всіх моїх тестів одразу після створення. Дженкінс, ІС, який я зараз використовую, також працює і надає результати тестів та дані про покриття.

Можливо, можливо, додати в свій IDE користувальницький запуск для файлу для запуску одиничних тестів для файлу Foo.cpp, якщо ви випадково назвали всі одиничні тести для Foo під тестовим кріпленням TestFoo. Як налаштувати це саме для Visual-C ++ Я не впевнений, але я думаю, що це можливо.

Я використовую MSTest для тестування нативного C ++ коду.
Ось чудовий пост у цьому блозі: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c. асп

Так, буде щонайменше два проекти - один для самої заявки, один для тестів.
Замість того, щоб робити третій проект зі статичною бібліотекою, я просто додаю джерело програми до тестового проекту, тому рішення виглядає так:

[-] Solution 'Foo'      Foo\Foo.sln
 |-[-] Foo              Foo\Foo\Foo.vcproj
 |  |-[-] include
 |  |  |- foo.h         Foo\Foo\foo.h
 |  |  |- bar.h         Foo\Foo\bar.h
 |  |
 |  |-[-] source
 |     |- foo.cpp       Foo\Foo\foo.cpp
 |
 |-[-] Foo.Tests        Foo\Foo.Tests\Foo.Tests.vcproj
    |                        (Additional include directory: "..\Foo")
    |-[-] include
    |  |- FakeBar.h     Foo\Foo.Tests\FakeBar.h
    |
    |-[-] source
       |-[-] app
       |  |- foo.cpp    Foo\Foo\foo.cpp    -- not in Foo.Tests\
       |
       |-[-] unit-tests
          |- foo_Tests.cpp   Foo\Foo.Tests\foo_Tests.cpp
          |- bar_Tests.cpp   Foo\Foo.Tests\bar_Tests.cpp

Можливо, трохи пізно вдень, але якщо я правильно прочитав ваше запитання, ви шукаєте методи для покращення циклу TDD? Тут не згадувалося, але ви подивилися на події після побудови у VS?

Наші рішення зазвичай організовані (із показаними залежностями проекту) ...

MAIN-APP > LIB1, LIB2, UNIT-TEST-APP
UNIT-TEST-LIB1 > LIB1
UNIT-TEST-LIB2 > LIB2
UNIT-TEST-APP > UNIT-TEST-LIB1, UNIT-TEST-LIB2

Подія після складання MAIN-APP запустить UNIT-TEST-APP

Подія після складання UNIT-TEST-APP запуститься сама (просто поставте "$ (TargetPath)" як команду для запуску в події після складання).

(Це означає, що при побудові MAIN-APP модульні тести можуть виконуватися двічі, але це насправді не було проблемою в нашому випадку!)

Як уже згадувалося, так, для створення цієї структури докладено трохи зусиль, але як тільки вона є, додавання тестів просте.

Отже, все, що вам потрібно зробити, - це створити основне додаток, і тести для одиниць будуть запускатися автоматично!

Ну, не знаю, чи це допомагає, але є кілька чудових відео про TDD від Brett L. Schuchert. На жаль, він не показує поєднання "C ++" та "VS", але

TDD з C # і VS: http://vimeo.com/album/210446

TDD з C ++ та Eclipse: http://vimeo.com/13240481

Можливо, ви зможете це випрацювати з цих двох.

EDIT: Звичайно, відео C ++ стосується використання тестування фреймворків CppUTest з Eclipse, звичайно. Коли я опублікував це, я подумав, що його слід легко прийняти для використання у VS. Тож я трохи погуглив і виявив таке:

http://schuchert.wikispaces.com/tdd.cpp.NotesOnCppUTest

яка дає вам інформацію про те, як користуватися CppUTest у Visual Studio.

Googletest
Як інтегрувати з VC ++

Вам не потрібен плагін, тест - це ще одна ціль. Немає плагінів, щоб генерувати тест на c ++, evne, якщо ви могли б, це тестування безглуздих матеріалів, таких як завдання

Не можу коментувати інструменти C ++, оскільки я не торкався приблизно 20 років (.NET Dev в ці дні), і, мабуть, більшість інструментів у ці дні призначені для керованого коду, але щодо техніки ...

Як уже згадували інші, тестовий код завжди є зовсім іншим проектом / складанням, ніж виробничий код, і так, зазвичай, вам доведеться підтримувати цей проект самостійно, хоча, безумовно, у VS IDE це не велика проблема, оскільки у вас часто є кілька проектів, оскільки частина вашого рішення все одно.

Виробничий код є і повинен бути написаний дещо іншим для TDD. Під час написання тестів спершу вам доведеться спроектувати код, який можна перевірити. Це сама інша тема сама по собі, але це може зайняти час і здається дуже неприємним спочатку, особливо якщо ваші IDE / інструменти не дають вам швидкого зворотного зв’язку, обстріл для запуску інструментів командного рядка для запуску тестів просто руйнівний.

Існує безліч специфічних прийомів для того, щоб зробити код перевіряючим, але більшість з них розбиваються на створення невеликих об'єктів, які не роблять багато, так що ви можете перевірити їх ізольовано і мати можливість ввести тестову версію певної поведінки в більш складну об’єкти. Тут можуть багато допомогти рамки МОК.

Книга, яка вам може бути корисною, є; Майкл Перо, Ефективно працюючи зі спадковим кодексом. Це використовує кілька мов у своїх прикладах і може допомогти вам визначити конкретні підходи до безпечної адаптації коду / методи, які спочатку не були розроблені для перевірки.

Невеликий застереження: я п’яний від Agile Kool-Aid років тому: D

Maven не використовується широко в C ++ (все-таки він використовується в основному для Java, але є мовним агностиком), але це дуже потужний інструмент і дозволяє зберігати все в одному проекті (включаючи тести, насправді, це рекомендується підхід з Мейвен). Я пропоную це лише зараз, оскільки з відповідей поки що виглядає альтернатива плагіну VS, можливо, не існує.

Пошук плагінів я знайшов:

http://incubator.apache.org/npanday/

але, схоже, це ще не дуже зріло. З настройкою Maven все, що вам потрібно зробити для запуску тестів, виконується mvn testв командному рядку.

Якщо ви зацікавлені, ви можете дізнатися про це тут і (один із) підтримуючих плагінів C ++ тут (Maven має архітектуру плагінів, тому все є плагіном).

Рамкова рекомендація: У нашому офісі ми використовуємо TestDriven.NET, який інтегрується з Visual Studio. Класи одиничних тестів записуються на C ++ / CLI, який потім може викликати будь-який нативний код, який потрібно перевірити. Так, класи C ++ / CLI переходять у власну збірку, таким чином проект (и) тестування додається до рішення.