누구나 Visual-C ++로 "실제"TDD를 수행하고 있습니까? 그렇다면 어떻게합니까? [닫은]

개발 테스트 주도는 의미 코드 전에 테스트를 작성 하고 다음과 같은 특정주기 :

• 쓰기 테스트
• 검사 확인 (실행)
• 생산 코드 작성
• 검사 확인 (실행)
• 생산 코드 정리
• 테스트 확인 (실행)

내가 아는 한, 이것은 개발 솔루션으로 프로덕션 코드와 테스트 코드를 매우 빠르게 전환하고 특정 프로덕션 코드 부분에 대한 테스트를 매우 빠르게 수행 할 수있는 경우에만 가능합니다.

이제 C ++ (Bost.Test atm을 사용하고 있습니다)에 대한 단위 테스트 프레임 워크가 많이 있지만 TDD를 만드는 괜찮은 ( 기본 C ++의 경우 ) Visual Studio (플러그인) 솔루션이 실제로 존재 하지 않는 것 같습니다. 사용 된 프레임 워크에 관계없이 견딜 수있는 사이클.

"Bearable"은 별도의 테스트 프로젝트 등을 수동으로 설정하지 않고 특정 cpp 파일에 대해 테스트를 실행하는 원 클릭 동작임을 의미합니다. "Bearable"은 간단한 테스트가 시작 (연결!)되어 매우 빠르게 실행됨을 의미합니다. .

그렇다면 Visual Studio를 사용하여 네이티브 C ++ 개발에 TDD주기를 가능하게하는 도구 (플러그인) 및 기술은 무엇입니까?

참고 : 무료 또는 "상업용"도구를 사용하는 것이 좋습니다.

참고 : 프레임 워크 권장 사항이 없습니다 . 프레임 워크에 전용 Visual Studio 플러그인이없고 플러그인을 권장하지 않는 한.

편집 참고 : 지금까지 답변은 단위 테스트 프레임 워크를 Visual Studio에 통합하는 방법에 대한 링크를 제공했습니다. 리소스는 UT 프레임 워크가 컴파일하고 첫 번째 테스트를 실행하는 방법에 대해 다소 설명합니다. 이것은 이 질문에 관한 것이 아닙니다 . 실제로 생산성을 높이고 수동으로 유지 관리하는 (!) 단위 테스트를 사용하여 생산 클래스와 분리 된 vcproj를 사용하면 TDD가 불가능하다는 오버 헤드가 더 커질 것이라고 생각합니다. 내가 아는 한, 단위 테스트 및 TDD를 활성화하기 위해 Java 또는 C #에 추가 "프로젝트"를 추가 하지 않는 것이 좋습니다. 이것은 해야 올바른 도구가 주어지면 C ++로 가능하지만 TDD / C ++ / VS를위한 도구는 거의없는 것 같습니다.

인터넷 검색 을 통해 올바른 방향을 목표로하는 VisualAssert 도구를 발견 했습니다. 그러나 CppUnit, Boost.Test 등과 비교하여 널리 사용되지 않는 것 같습니다.

편집 :이 질문의 맥락에 의견을 추가하고 싶습니다. 나는 그것이 문제의 개요 (일부)에 대한 좋은 요약을한다고 생각한다 : ( Bill ONeal의 의견 )

Visual Studio는 사용자가 합리적으로 편집 할 수있는 "빌드 스크립트"를 사용하지 않습니다. 하나의 프로젝트는 하나의 바이너리를 생성합니다. 또한 Java는 Java가 완전한 바이너리를 빌드하지 않는다는 특성을 가지고 있습니다. 빌드하는 바이너리는 클래스 파일의 ZIP입니다. 따라서 별도로 컴파일 한 다음 JAR을 수동으로 함께 컴파일 할 수 있습니다 (예 : 7z 사용). C ++과 C #은 실제로 바이너리를 연결하므로 일반적으로 이와 같은 스크립트를 작성할 수 없습니다. 가장 가까운 것은 모든 것을 개별적으로 컴파일 한 다음 두 개의 연결 (하나는 프로덕션, 하나는 테스트)을 수행하는 것입니다.

: 나는 C ++ 및 Visual Studio와 TDD 일을 5 부분 블로그 시리즈를 작성한 1 부 , 2 부 , 3 부 , 4 부 , 5 부 .

TDD를 수행하기 위해 C #에서 추가 프로젝트를 만들지 않는 이유를 잘 모르겠습니다. 왜냐하면 이것이 NUnit으로 항상 수행 한 작업이므로 다른 사람들이 NUnit으로 수행하는 작업의 전형적인 것 같습니다. 그 이유는 간단합니다. 항상 테스트 코드를 프로덕션 코드와 별도로 유지하십시오. Visual Studio를 사용하는 C ++의 경우 이는 C # 및 NUnit과 마찬가지로 별도의 프로젝트를 의미합니다. Java 세계에 대해 아는 것에서 이것은 일반적입니다.

분명히, 모든 사람들은 TDD를 수행하는 데있어 "참을 수있는"것에 대해 다른 생각을 가지고 있습니다. 나는 지난 몇 년 동안 내 블로그 게시물에서 설명하는 방법을 연습 해 왔으며 그 방법이 매우 견딜 만하다고 생각합니다. C ++은 컴파일 된 언어이며 테스트중인 시스템이 고도로 결합되면 컴파일 속도가 느려질 수 있습니다. 좀 더 느슨하게 결합 된 디자인으로 리팩토링하지 않고는 그로부터 벗어날 수 없습니다.

내 "원 클릭 액션"은 "빌드 솔루션"입니다. 그것이 너무 많이 구축되면 작업하는 동안 항상 관련없는 프로젝트를 언로드 할 수 있으며 Build Solution은 변경 결과로 업데이트 할 필요가있는 최소한의 프로젝트만을 빌드합니다.

물론 C ++의 컴파일 시간 특성으로 인해 NUnit 및 C #보다 TDD 프로세스의 각 사이클에서 시간이 조금 더 오래 걸리지 만 잘 테스트 된 C ++ 코드에서 얻는 자신감은 그만한 가치가 있습니다. 그렇지 않으면 디버거에서 더 많은 시간을 할애 할 것입니다. 컴파일 시간을 테스트하기 위해 실질적으로 추가 할 수 있으므로 gmock 사용에주의를 기울여야합니다. 나는 지금까지 가벼운 "가짜"객체를 얻었고 모의 기능이 거의 필요하지 않습니다. C ++의 조롱 프레임 워크는 템플릿 기반으로되어 있으며 컴파일 시간을 크게 늘릴 수 있으므로 실제로 조롱이 필요한 위치와 가짜가 수행하지 않는 위치에 예약해야합니다.

생산 코드에 대한 테스트 프로젝트를 작성하는 보일러 플레이트 특성을 자동화하기 위해 Boost.Test 단위 테스트 프로젝트 마법사를 작성하는 것을 고려했지만 실제로 두 번 수행 한 후에는 수동으로 수행하기가 어렵지 않습니다.

많은 (150?) 프로젝트가있는 솔루션에 대해서는 그에 대처하는 방법이 있습니다. 한 가지 확실한 방법은 관련 프로젝트 그룹을 찾아 묶어 함께 소비하고 게시하는 것입니다. TDD주기 동안 수행하는 작은 변경 사항에 대해 150 개 프로젝트를 모두 다시 빌드 / 터치해야하는 경우 코드가 너무 많이 결합되어 단위 테스트가 큰 차이를 만들지 않습니다.

netbeans IDE 링크를 보면 테스트 출력을 구문 분석하고 녹색 또는 빨간색 기호가있는 창에서 NUnit에서 왔을 때 놓친 것으로 생각되는 작은 테스트 행을 보여주는 눈 사탕 을 발견 했습니다. 그러나 실제로 놓치지 않았다. 빌드가 단순히 실패하는 것이 더 유용하다는 것을 알았습니다. 오류 창에서 두 번 클릭하여 커서를 실패한 어설 션 위치에 배치 할 수 있습니다.

Visual-C ++을 사용하지 않지만 QtCreator를 IDE로 사용하여 googletest 및 googlemock을 사용하여 C ++로 TDD를 수행하고 있습니다. 몇 년 전 Visual-C ++와 비슷한 설정을 사용했지만 다른 단위 테스트 프레임 워크를 사용했습니다.

내가 찾은 것은 프로젝트를 몇 개의 하위 프로젝트로 분리하는 것입니다.

1. 실제 프로젝트 소스 코드의 99 %를 포함하는 정적 또는 동적 라이브러리.
2. 일반 프로그램을 실행하기 위해 주로 main () 메소드로 구성된 프로젝트.
3. 테스트 프레임 워크를 실행하기위한 main () 및 테스트 및 모의 객체를 포함하는 많은 파일을 포함하는 테스트 프로젝트.

이 설정을 사용하면 IDE에서 파일을 다양한 프로젝트에 추가하는 작업을 수행하고 종속성이 올바르게 결정되면 부분 재 구축으로 모든 단위 테스트를 실행할 수 있습니다. 심지어 빌드 후 즉시 모든 테스트를 실행하도록 설정했습니다. 현재 사용중인 CI 인 Jenkins도 실행되어 테스트 결과 및 적용 범위 데이터를 제공합니다.

테스트 픽스처 TestFoo에서 Foo에 대한 모든 단위 테스트의 이름을 지정한 경우 파일이 Foo.cpp에 대한 단위 테스트를 실행하도록 파일에 대해 IDE에 사용자 정의 실행기를 추가 할 수 있습니다. Visual-C ++에 대해 정확하게 설정하는 방법 확실하지 않지만 가능하다고 생각합니다.

네이티브 C ++ 코드를 테스트하기 위해 MSTest를 사용합니다.
이 방법에 대한 훌륭한 블로그 게시물은 다음과 같습니다. http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c. aspx

그렇습니다. 최소한 두 개의 프로젝트가 있습니다. 하나는 응용 프로그램 용이고 다른 하나는 테스트 용입니다.
정적 라이브러리로 세 번째 프로젝트를 만드는 대신 응용 프로그램 소스를 프로젝트 테스트에 추가하면 솔루션은 다음과 같습니다.

[-] 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를 만들 때 단위 테스트가 두 번 실행될 수 있지만 실제로는 문제가되지 않았다는 것을 의미합니다!)

언급했듯이, 이 구조를 설정 하는 데 약간 의 노력이 있지만 일단 설치되면 테스트를 추가하는 것이 간단합니다.

메인 앱을 빌드하기 만하면 유닛 테스트가 자동으로 실행됩니다!

이것이 도움이되는지 모르지만 Brett L. Schuchert의 TDD에 관한 훌륭한 비디오가 있습니다. 불행히도 그는 "C ++"와 "VS"의 조합을 보여주지 않지만

C # 및 VS를 사용한 TDD : http://vimeo.com/album/210446

C ++ 및 Eclipse를 사용한 TDD : http://vimeo.com/13240481

아마도 당신은 그 두 가지에서 그것을 해결할 수 있습니다.

편집 : C ++ 비디오는 물론 Eclipse에서 CppUTest 테스트 프레임 워크를 사용하는 것에 관한 것입니다. 게시했을 때 VS에서 사용하기에 쉽게 채택되어야한다고 생각했습니다. 그래서 나는 조금 구글 검색하고 이것을 발견 :

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

Visual Studio에서 CppUTest를 사용하는 방법에 대한 정보를 제공합니다.

Googletest는
어떻게 VC와 통합하는 ++

플러그인이 필요하지 않으며 테스트는 또 다른 대상입니다. C ++로 테스트를 생성하는 플러그인이 없습니다. 할당과 같은 의미없는 것을 테스트 할 수 있다면 evne

약 20 년 동안 만지지 않은 C ++ 도구 (요즘 .NET dev)에 대해서는 언급 할 수 없으며 요즘 대부분의 도구는 관리 코드 용이지만 기술과 관련이 있다고 생각합니다 ...

다른 사람들이 언급했듯이 테스트 코드는 항상 프로덕션 코드와 완전히 다른 프로젝트 / 어셈블리에 있으며 일반적으로 프로젝트를 직접 유지 관리해야하지만 VS IDE에서는 확실히 여러 프로젝트가 있으므로 큰 문제는 아닙니다. 어쨌든 솔루션의 일부입니다.

생산 코드는 TDD에 대해 약간 다르게 작성되어야합니다. 테스트를 먼저 작성할 때 테스트 할 수 있도록 코드를 설계해야합니다. 이것은 그 자체로 완전히 다른 주제이지만 시간이 걸리고 특히 IDE / 도구가 빠른 피드백을 제공하지 않는 경우 특히 좌절감을 느낄 수 있습니다. 테스트를 실행하기 위해 명령 줄 도구를 실행하여 테스트를 실행하는 것은 방해가됩니다.

코드를 테스트 할 수있게하는 많은 특정 기술이 있지만, 대부분 별다른 기능을하지 않는 작은 객체를 만드는 데 사용되므로 격리 된 상태에서 테스트하고 일부 동작의 테스트 버전을 더 복잡한 곳에 주입 할 수 있습니다 사물. IOC 프레임 워크는 여기서 많은 도움이 될 수 있습니다.

유용한 책은 다음과 같습니다. 레거시 코드를 효과적으로 사용하는 Michael Feathers 이 예제에서는 여러 언어를 사용하며 원래 테스트 할 수 있도록 설계되지 않은 코드 / 기술을 안전하게 적용하기위한 특정 접근 방식을 식별하는 데 도움이 될 수 있습니다.

작은 경고 : 나는 몇 년 전 Agile Kool-Aid에서 취했습니다 : D

Maven은 C ++에서 널리 사용되지는 않지만 (아마 Java에 주로 사용되지만 언어에 구애받지 않습니다) 매우 강력한 도구이며 모든 것을 하나의 프로젝트 (실제 테스트를 포함하여)로 유지할 수 있습니다 Maven과의 접근). 지금까지 답변에서 VS 플러그인이없는 대안처럼 보일 수 있기 때문에 지금 만 제안합니다.

내가 찾은 플러그인 검색 :

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

그러나 아직 성숙하지 않은 것 같습니다. Maven 설정을 사용하면 테스트를 실행하기 위해 수행해야 할 모든 작업 mvn test이 명령 줄에서 실행됩니다.

관심이 있다면 여기에서 그리고 여기 에서 C ++ 지원 플러그인을 배울 수 있습니다 (Maven에는 플러그인 아키텍처가 있으므로 모든 것이 플러그인입니다).

프레임 워크 권장 사항 : 사무실에서는 Visual Studio와 통합되는 TestDriven.NET을 사용합니다. unittest 클래스는 C ++ / CLI로 작성되며, 테스트해야 할 기본 코드를 연습 할 수 있습니다. 그렇습니다. C ++ / CLI 클래스는 자체 어셈블리에 들어가므로 "테스트"프로젝트가 솔루션에 추가되었습니다.