Czy ktoś robi „prawdziwe” TDD z Visual-C ++, a jeśli tak, jak to robi? [Zamknięte]

Rozwój oparty na testach oznacza napisanie testu przed kodem i wykonanie określonego cyklu :

• Napisz test
• Sprawdź test (uruchom)
• Napisz kod produkcji
• Sprawdź test (uruchom)
• Wyczyść kod produkcji
• Sprawdź test (uruchom)

Moim zdaniem jest to możliwe tylko wtedy, gdy twoje rozwiązanie programistyczne pozwala bardzo szybko przełączać się między kodem produkcyjnym i testowym oraz bardzo szybko wykonywać test dla określonej części kodu produkcyjnego.

Teraz, mimo że istnieje wiele frameworków do testowania jednostek dla C ++ (używam bankomatu Bost.Test.), Wydaje się, że tak naprawdę nie istnieje żadne przyzwoite (dla natywnego C ++ ) rozwiązanie Visual Studio (Plugin), które tworzy TDD cykl znośny bez względu na zastosowane ramy.

„Znośny” oznacza, że ​​uruchamianie testu określonego pliku cpp odbywa się jednym kliknięciem bez konieczności ręcznego konfigurowania osobnego projektu testowego itp. „Znośny” oznacza również, że rozpoczyna się prosty test (łączenie!) I działa bardzo szybko .

Jakie narzędzia (wtyczki) i techniki są dostępne, dzięki czemu cykl TDD jest możliwy do tworzenia natywnego C ++ w Visual Studio?

Uwaga: Nie mam nic przeciwko darmowym lub „komercyjnym” narzędziom.

Proszę : Brak zaleceń ramowych. (Chyba że framework ma dedykowaną wtyczkę Visual Studio i chcesz ją polecić).

Edytuj notatkę : Dotychczasowe odpowiedzi zawierały łącza do sposobu zintegrowania frameworku testów jednostkowych z Visual Studio. Zasoby mniej więcej opisują sposób, w jaki środowisko UT kompiluje się i uruchamia pierwsze testy. Nie o to chodzi w tym pytaniu. Jestem zdania, że ​​aby naprawdę produktywnie pracować, mając Testy Jednostkowe w ręcznie utrzymywanym (!) Oddzielnym vcproj od twoich klas produkcyjnych dodasz tak dużo narzutu, że TDD „nie jest możliwe”. O ile mi wiadomo, nie dodajesz dodatkowych „projektów” do rzeczy Java lub C #, aby włączyć Testy Jednostkowe i TDD, i to nie bez powodu. To powinno być możliwe z C ++ przy odpowiednich narzędziach, ale wydaje się (chodzi o to pytanie), że jest bardzo mało narzędzi dla TDD / C ++ / VS.

Googlując się, znalazłem jedno narzędzie, VisualAssert , które wydaje się zmierzać we właściwym kierunku. Jednak afaiks nie wydaje się być w powszechnym użyciu (w porównaniu do CppUnit, Boost.Test itp.).

Edycja: Chciałbym dodać komentarz do kontekstu tego pytania. Myślę, że to dobre podsumowanie zarysowania (części) problemu: (komentarz Billy ONeal )

Program Visual Studio nie używa „skryptów kompilacji”, które użytkownik może w rozsądny sposób edytować. Jeden projekt tworzy jeden plik binarny. Co więcej, Java ma właściwość, że Java nigdy nie buduje pełnego pliku binarnego - plik binarny, który budujesz, jest tylko ZIP-em plików klas. Dlatego możliwe jest ręczne kompilowanie, a następnie JAR razem ręcznie (używając np. 7z). Zarówno C ++, jak i C # faktycznie łączą ich pliki binarne, więc ogólnie mówiąc, nie można napisać takiego skryptu. Najbliższe, co możesz uzyskać, to skompilować wszystko osobno, a następnie wykonać dwa połączenia (jedno dla produkcji, jedno dla testowania).

Napisałem 5-częściową serię blogów na temat robienia TDD z C ++ i Visual Studio: część 1 , część 2 , część 3 , część 4 , część 5 .

Nie jestem pewien, dlaczego mówisz, że nie tworzysz dodatkowych projektów w języku C #, aby robić TDD, ponieważ zawsze tak robiłem z NUnit i wydaje się to typowe dla tego, co inni ludzie robią również z NUnit. Powód jest prosty: zawsze trzymaj kod testowy oddzielnie od kodu produkcyjnego. W przypadku C ++ z Visual Studio oznacza to oddzielne projekty, podobnie jak w przypadku C # i NUnit. Z tego, co wiem o świecie Java, jest to również powszechne.

Oczywiście każdy ma inne wyobrażenia na temat tego, co jest „do zniesienia” przy robieniu TDD. Ćwiczę metodę opisaną w moim blogu od wielu lat i uważam ją za bardzo znośną. C ++ jest językiem kompilowanym, a kompilacja może być powolna, gdy testowany system jest silnie sprzężony. Po prostu nie da się od tego uciec bez zmiany na bardziej luźny projekt.

Moje „działanie jednym kliknięciem” to „Kompiluj rozwiązanie”. Jeśli to za dużo buduje, zawsze możesz zwolnić nieistotne projekty podczas pracy, a następnie Build Solution zbuduje tylko minimalny podzbiór projektów, które należy zaktualizować w wyniku wprowadzonych zmian.

To prawda, że ​​czas kompilacji C ++ w czasie kompilacji sprawia, że ​​zajmuje to trochę więcej czasu w każdym cyklu procesu TDD niż w przypadku NUnit i C #, ale pewność, którą czerpię z dobrze przetestowanego kodu C ++ jest tego warta. W przeciwnym razie spędzę dużo więcej czasu w debuggerze. Zachowam ostrożność, aby oszczędzić na używaniu gmocka, ponieważ może to znacznie wydłużyć czas testowania kompilacji. Do tej pory głównie uciekałem od lekkich „fałszywych” obiektów i rzadko potrzebuję pełnej funkcjonalności makiet. Frameworki frameworków dla C ++ są w dużej mierze oparte na szablonach, co może znacznie wydłużyć czas kompilacji, więc powinny być zarezerwowane tam, gdzie naprawdę potrzebujesz makiety, a fałszywy po prostu tego nie zrobi.

Zastanawiałem się nad stworzeniem kreatora projektu testu jednostkowego Boost.Test, aby zautomatyzować część projektu tworzenia kodu testowego dla kodu produkcyjnego, ale po kilkukrotnym wykonaniu naprawdę nie jest to takie trudne ręcznie.

Jeśli chodzi o rozwiązania z wieloma (150?) Projektami, istnieją również sposoby radzenia sobie z tym. Jednym z oczywistych jest znalezienie grup powiązanych projektów i zebranie ich w całość oraz rozpoczęcie ich konsumpcji / publikowania jako całości. Jeśli naprawdę potrzebujesz przebudować / dotknąć wszystkich 150 projektów w celu wprowadzenia drobnych zmian, które wprowadzasz podczas cyklu TDD, to i tak kod jest tak bardzo sprzężony, że testy jednostkowe raczej nie będą miały większego znaczenia.

Patrząc na link NetBeans IDE, znajdę eye candy posiadania czegoś, analizuje wyjścia testowego i pokazuje mały test wiersz w oknie z zielonym lub czerwonym symbolem obok niej coś, co mi minie które pochodzą z NUnit, ale tak naprawdę nie przegapiłem. Uważam, że bardziej przydatne jest po prostu niepowodzenie kompilacji, a następnie mogłem kliknąć dwukrotnie w oknie błędów, aby umieścić kursor w miejscu nieudanego potwierdzenia.

Nie używam Visual-C ++, ale wykonuję TDD z C ++, używając googletest i googlemock, z QtCreator jako moim IDE. Wiele lat temu miałem podobną konfigurację z Visual-C ++, ale używając innej struktury testów jednostkowych.

Za użyteczne uznałem podzielenie projektu na kilka podprojektów.

1. Biblioteka statyczna lub dynamiczna, która zawiera 99% rzeczywistego kodu źródłowego projektu.
2. Projekt składający się głównie z metody main () do uruchomienia normalnego programu.
3. Projekt testowy, który zawiera main () do uruchomienia mojego środowiska testowego i wiele plików zawierających testy i obiekty próbne.

Dzięki tej konfiguracji moje IDE zajmuje się dodawaniem plików do różnych projektów, a jeśli zależności są poprawnie określone, mogę uruchomić wszystkie moje testy jednostkowe z częściową przebudową. Mam nawet tę konfigurację, aby uruchamiała wszystkie moje testy natychmiast po skompilowaniu. Jenkins, CI, którego obecnie używam, również działa i zapewnia wyniki testów oraz dane dotyczące zasięgu.

Możliwe jest dodanie niestandardowego programu uruchamiającego do IDE dla pliku, aby uruchomić testy jednostkowe dla pliku Foo.cpp, jeśli zdarzyło Ci się nazwać wszystkie testy jednostkowe dla Foo w urządzeniu testowym TestFoo. Jak skonfigurować to dokładnie dla Visual-C ++ Nie jestem pewien, ale myślę, że to możliwe.

Używam MSTest do testowania natywnego kodu C ++.
Oto świetny post na blogu na ten temat: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c. aspx

Tak, będą co najmniej dwa projekty - jeden dla samej aplikacji, drugi dla testów.
Zamiast tworzyć trzeci projekt ze statyczną biblioteką, po prostu dodaję źródło aplikacji do testowania projektu, więc rozwiązanie wygląda następująco:

[-] 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

Może trochę późno w ciągu dnia, ale jeśli poprawnie przeczytam twoje pytanie, szukasz technik, które poprawią cykl TDD? Nie wspomniano tutaj, ale czy oglądałeś wydarzenia po kompilacji w VS?

Nasze rozwiązania są zazwyczaj zorganizowane (z pokazanymi zależnościami projektu) ...

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

Wydarzenie po kompilacji MAIN-APP uruchomi UNIT-TEST-APP

Zdarzenie po kompilacji UNIT-TEST-APP uruchomi się samo (wystarczy wpisać „$ (TargetPath)” jako polecenie do uruchomienia w zdarzeniu po kompilacji).

(Oznacza to, że podczas budowania GŁÓWNEJ APLIKACJI testy jednostkowe mogą przebiegać dwukrotnie, ale w naszym przypadku nie był to problem!)

Jak już wspomniano, tak, konfiguracja tej struktury wymaga trochę wysiłku, ale kiedy już się pojawi, dodawanie testów jest proste.

Wszystko, co musisz zrobić, to zbudować główną aplikację, a testy jednostkowe uruchomią się automatycznie!

Cóż, nie wiem, czy to pomaga, ale jest kilka świetnych filmów o TDD autorstwa Bretta L. Schucherta. Niestety nie pokazuje kombinacji „C ++” i „VS”, ale

TDD z C # i VS: http://vimeo.com/album/210446

TDD z C ++ i Eclipse: http://vimeo.com/13240481

Być może możesz to rozwiązać na podstawie tych dwóch.

EDYCJA: wideo w C ++ dotyczy oczywiście użycia ramy testowej CppUTest z Eclipse. Kiedy go opublikowałem, pomyślałem, że powinien być łatwo przystosowany do użycia w VS. Więc trochę google i znalazłem to:

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

który daje informacje, jak korzystać z CppUTest w Visual Studio.

Googletest
Jak zintegrować z vc ++

Nie potrzebujesz wtyczki, test to kolejny cel. Nie ma wtyczek do generowania testu przy pomocy c ++, na przykład gdybyś mógł testować niepotrzebne rzeczy, takie jak przypisania

Nie mogę komentować narzędzi C ++, których nie dotknąłem od około 20 lat (obecnie .NET Dev) i wydaje mi się, że większość narzędzi w dzisiejszych czasach służy do kodu zarządzanego, ale jak do technik ...

Jak wspomnieli inni, kod testowy jest zawsze w zupełnie innym projekcie / zestawie niż kod produkcyjny i tak, zwykle musisz sam utrzymywać ten projekt, chociaż z pewnością w VS IDE nie jest to duży problem, ponieważ często masz kilka projektów, takich jak i tak część twojego rozwiązania.

Kod produkcyjny jest i musi być napisany nieco inaczej dla TDD. Podczas pisania testów najpierw musisz zaprojektować kod, aby był testowalny. Jest to zupełnie inny temat sam w sobie, ale na początku może wydawać się bardzo frustrujący, szczególnie jeśli twoje IDE / narzędzia nie dają ci szybkiej informacji zwrotnej, wystrzelenie w celu uruchomienia narzędzi wiersza poleceń do uruchomienia testów jest po prostu uciążliwe.

Istnieje wiele specyficznych technik umożliwiających testowanie kodu, ale większość z nich dzieli się na tworzenie małych obiektów, które niewiele robią, dzięki czemu można je testować w izolacji i możliwość wstrzyknięcia testowej wersji niektórych zachowań w bardziej złożone przedmioty Ramy MKOl mogą tu bardzo pomóc.

Przydatna jest książka; Michael Feathers, Efektywnie współpracujący ze starszym kodem. Używa wielu języków w swoich przykładach i może pomóc w określeniu konkretnych podejść do bezpiecznego dostosowania kodu / technik, które nie zostały pierwotnie zaprojektowane do testowania.

Małe zastrzeżenie: piłem z Agile Kool-Aid lata temu: D

Maven nie jest powszechnie używany w C ++ (ale jest głównie używany w Javie, ale jest niezależny od języka), ale jest to bardzo potężne narzędzie i pozwala zachować wszystko w jednym projekcie (w tym testy, w rzeczywistości jest to zalecane podejście z Maven). Sugeruję to teraz, ponieważ z dotychczasowych odpowiedzi wygląda na to, że alternatywa dla wtyczki VS może nie istnieć.

W poszukiwaniu wtyczek znalazłem:

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

ale nie wygląda jeszcze na bardzo dojrzały. Z instalacją Maven wszystko, co musisz zrobić, aby uruchomić testy, jest uruchamiane mvn testz wiersza poleceń.

Jeśli jesteś zainteresowany, możesz dowiedzieć się o tym tutaj i (jednej z) wtyczek obsługujących C ++ tutaj (Maven ma architekturę wtyczek, więc wszystko jest wtyczką).

Zalecenia ramowe: w naszym biurze używamy TestDriven.NET, który integruje się z Visual Studio. Unittest klasy są napisane w C ++ / CLI, które mogą następnie wywoływać dowolny natywny kod, który potrzebujesz przetestować. Tak, klasy C ++ / CLI wchodzą we własny zestaw, dlatego do rozwiązania (rozwiązań) dodano projekt „testowania”.