Visual-C ++で「実際の」TDDをしている人はいますか。[閉まっている]

テスト駆動開発とは、コードの前にテストを記述し、特定のサイクルを実行することを意味します。

• テストを書く
• テストの確認（実行）
• 量産コードを書く
• テストの確認（実行）
• プロダクションコードのクリーンアップ
• テストをチェック（実行）

私に関する限り、これは、開発ソリューションでプロダクションコードとテストコードを非常に迅速に切り替え、特定のプロダクションコード部分のテストを非常に迅速に実行できる場合にのみ可能です。

今、C ++には多くの単体テストフレームワークが存在しますが（Bost.Test atmを使用しています）、TDDを作成する適切な（ネイティブC ++の）Visual Studio（Plugin）ソリューションは実際には存在しないようです。使用されるフレームワークに関係なく耐えられるサイクル。

「ベアラブル」とは、個別のテストプロジェクトなどを手動で設定しなくても、特定のcppファイルのテストを実行するのがワンクリックのアクションであることを意味します。 。

では、Visual Studioを使用したネイティブC ++開発でTDDサイクルを可能にするツール（プラグイン）とテクニックはどこにありますか？

注：私は無料または「商用」ツールで大丈夫です。

してください：ノーフレームワーク勧告。（フレームワークに専用のVisual Studioプラグインがあり、そのプラグインを推奨する場合を除きます。）

注の編集：これまでの回答は、ユニットテストフレームワークをVisual Studioに統合する方法に関するリンクを提供しています。リソースは多かれ少なかれ、UTフレームワークをコンパイルして最初のテストを実行する方法を説明しています。これはこの質問についてではありません。ユニットテストを手動で維持（！）して実際に生産的に作業するには、vcprojを本番クラスから分離するとオーバーヘッドが大きくなり、TDDが「不可能」になると私は思います。私が知る限り、JavaまたはC＃のモノに追加の「プロジェクト」を追加してユニットテストとTDDを有効にしないでください。これは 適切なツールを与えられたC ++で可能になるが、TDD / C ++ / VS用のツールはほとんどないようです（この質問についてです）。

探し回って、正しい方向を目指しているように見えるVisualAssertというツールを見つけました。しかし、残念ながら、広く使われているようには見えません（CppUnit、Boost.Testなどと比較して）。

編集：この質問のコンテキストにコメントを追加します。問題の概要（の一部）の良い要約を示していると思います：（Billy ONealによるコメント）

Visual Studioは、ユーザーが合理的に編集可能な「ビルドスクリプト」を使用しません。1つのプロジェクトで1つのバイナリが生成されます。さらに、Javaには、Javaが完全なバイナリを決して構築しないという特性があります-構築するバイナリは、クラスファイルの単なるZIPです。したがって、個別にコンパイルしてから、JARを手動で（たとえば、7zを使用して）コンパイルすることが可能です。C ++とC＃はどちらも実際にはバイナリをリンクしているため、一般的に言えば、そのようなスクリプトを作成することはできません。あなたが得ることができる最も近いのは、すべてを別々にコンパイルしてから、2つのリンクを行うことです（1つは本番用、もう1つはテスト用）。

C ++とVisual StudioでTDDを実行する5部構成のブログシリーズを作成しました（パート1、パート2、パート3、パート4、パート5）。

T＃を行うためにC＃で追加のプロジェクトを作成しないと言う理由がわかりません。これは、私がNUnitで常に行ってきたことであり、他の人々がNUnitでも行う典型的なことのようです。理由は簡単です。常にテストコードと製品コードを分離しておくことです。Visual Studioを使用するC ++の場合、これはC＃とNUnitの場合と同様に、個別のプロジェクトを意味します。私がJavaの世界について知っていることから、これはそこでも一般的です。

明らかに、TDDを実行するために「耐えられる」ものについては、誰もが異なる考えを持っています。私は私のブログ記事で概説した方法を非常に長い間実践してきましたが、それは非常に我慢できると思います。C ++はコンパイルされた言語であり、テスト対象のシステムが高度に結合されていると、コンパイルに時間がかかる場合があります。より緩やかに結合された設計にリファクタリングしない限り、そこから抜け出すことはできません。

私の「ワンクリックアクション」は「ソリューションのビルド」です。ビルドが多すぎる場合は、作業中に無関係なプロジェクトをいつでもアンロードでき、Build Solutionは変更の結果として更新する必要のあるプロジェクトの最小限のサブセットのみをビルドします。

確かに、C ++のコンパイル時間の性質により、これはTDDプロセスの各サイクルでNUnitやC＃を使用した場合よりも少し時間がかかりますが、十分にテストされたC ++コードから得られる信頼性は価値があります。それ以外の場合は、デバッガで多くの時間を費やすことになります。テストのコンパイル時間を大幅に増加させる可能性があるため、gmockの使用を控えるように注意してください。これまでのところ、ほとんどの場合、軽量の「偽造」オブジェクトを使用していないため、モックの本格的な機能はほとんど必要ありません。C ++のモックフレームワークは非常にテンプレートベースであり、これによりコンパイル時間が大幅に増加する可能性があるため、実際にモックが必要であり、偽物が必要としない場所のために予約する必要があります。

私はBoost.Test単体テストプロジェクトウィザードを作成して、量産コードのテストプロジェクトを作成するボイラープレートの性質の一部を自動化することを検討しましたが、数回実行すると、手動で行うのはそれほど難しくありません。

多くの（150？）プロジェクトを含むソリューションについては、それに対処する方法もあります。明らかなことの1つは、関連するプロジェクトのグループを見つけてそれらをまとめ、それらを1つの単位として消費/公開することです。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 ++用に正確に設定する方法はわかりませんが、可能だと思います。

MSTestを使用してネイティブC ++コードをテストしています。
この方法についての素晴らしいブログ投稿は次のとおりです。http：//blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c。 aspx

はい、少なくとも2つのプロジェクトがあります。1つはアプリケーション自体用、もう1つはテスト用です。
静的ライブラリを使用して3番目のプロジェクトを作成する代わりに、アプリケーションのソースをテストプロジェクトに追加するだけなので、ソリューションは次のようになります。

[-] 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をビルドするときにユニットテストが2回実行される可能性があることを意味しますが、それは私たちのケースでは本当に問題ではありませんでした！）

ただし、前述のとおり、はい、この構造の設定には少し労力が必要ですが、いったんそこに配置されれば、テストの追加は簡単です。

したがって、メインアプリをビルドするだけで、ユニットテストが自動的に実行されます。

これが役立つかどうかはわかりませんが、Brett L. SchuchertによるTDDに関するすばらしいビデオがいくつかあります。残念ながら、彼は「C ++」と「VS」の組み合わせを示していませんが、

C＃およびVSでのTDD：http : //vimeo.com/album/210446

C ++およびEclipseを使用したTDD：http : //vimeo.com/13240481

多分あなたはそれらの2つからそれを解決することができます。

編集：C ++ビデオはもちろん、EclipseでCppUTestテストフレームワークを使用することについてです。それを投稿したとき、VSでの使用に簡単に採用できるはずだと思いました。だから私は少しグーグルしてこれを見つけました：

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

Visual StudioでCppUTestを使用する方法に関する情報を提供します。

Googletest
VC ++と統合する方法

プラグインは必要ありません。テストは別のターゲットです。c ++でテストを生成するプラグインはありません。割り当てなどの無意味なものをテストすることができれば可能です。

私は約20年間触れていないので（最近の.NET開発）、C ++ツールについてコメントできません。最近のツールのほとんどはマネージコード用ですが、テクニックについては...

他の人が述べたように、テストコードは常に本番コードとは完全に異なるプロジェクト/アセンブリにあり、通常は自分でプロジェクトを維持する必要がありますが、VS IDEでは確かにこれは大きな問題ではなく、とにかくあなたのソリューションの一部。

量産コードは、TDDとは少し異なります。最初にテストを作成するとき、テスト可能なようにコードを設計する必要があります。これ自体は他のテーマですが、最初は時間がかかり、最初は非常にイライラするかもしれません。特に、IDE /ツールから迅速なフィードバックが得られない場合は、コマンドラインツールを実行してテストを実行すると、混乱を招くだけです。

コードをテスト可能にするための特定のテクニックはたくさんありますが、それらのほとんどは、あまり機能しない小さなオブジェクトを作成することに分解されるため、それらを個別にテストして、いくつかの動作のテストバージョンをより複雑なものに注入できます。オブジェクト。IOCフレームワークは、ここで非常に役立ちます。

あなたが役に立つと思う本は、マイケルフェザー、レガシーコードを効果的に使用。これは、その例で複数の言語を使用しており、元々テスト可能であるように設計されていなかったコード/技法を安全に適合させるための特定のアプローチを識別するのに役立つ場合があります。

小さな注意：私は数年前にアジャイルクールエイドから酔っていました：D

MavenはC ++で広く使用されていません（まだJavaで主に使用されていますが、言語に依存しません）は非常に強力なツールであり、1つのプロジェクトのすべてを維持できます（実際、テストを含む、これは推奨されます） Mavenとのアプローチ）。これまでの回答から、VSプラグインを使用した代替案は存在しない可能性があるため、私は今それを提案するだけです。

私が見つけたプラグインを検索しています：

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

まだ成熟していないようです。Mavenセットアップを使用すると、テストを実行するために必要なことはすべてmvn testコマンドラインで実行されます。

興味がある場合は、こことC ++をサポートするプラグインの1つをここで学習できます（Mavenにはプラグインアーキテクチャがあるため、すべてがプラグインです）。

フレームワークの推奨事項：私たちのオフィスでは、Visual Studioと統合するTestDriven.NETを使用しています。ユニットテストクラスはC ++ / CLIで記述されており、テストする必要のあるネイティブコードを呼び出すために呼び出すことができます。はい、C ++ / CLIクラスは独自のアセンブリに組み込まれるため、ソリューションに「テスト」プロジェクトが追加されます。