コンソールアプリケーションとして実行するBoostユニットテストのコレクションがあります。
プロジェクトで作業してテストを実行するとき、テストをデバッグできるようにしたいので、テストの実行後にコンソールを開いたままにしておきたいと思います。
リリースモードで実行すると、プログラムの終了後にコンソールウィンドウが表示されたままになりますが、デバッグモードではそうではありません。
'system( "pause");'を追加したくないまたは、私のプログラムでキャラクターを読むような他のハッキング。リリースモードで実行している場合のように、デバッグを使用してテストを実行した後、Visual Studioを一時停止させたいだけです。また、テストの出力がVisual Studioの出力ウィンドウの1つでキャプチャされた場合も気に入っていますが、それは本来よりも難しいようです。
これどうやってするの?
ブーストテストでは、次の Visual Studioの使用に関する推奨事項 が提供されます。これにより、コンパイルの最後にユニットテストを自動的に実行し、ビルドウィンドウに出力をキャプチャできます。
このトリックの素晴らしい副作用は、テストの失敗をコンパイルエラーとして扱うことができることです。 「...これらのエラーは、コンパイルエラー分析に使用する通常のキーボードショートカット/マウスクリックを使用してジャンプできます...」
でアプリケーションを実行してみてください Ctrl + F5 組み合わせ。
古いバージョンでは、「空のプロジェクト」を選択した場合でも、デフォルトではコンソールサブシステムになりますが、2010ではそうではないため、手動で設定する必要があります。これを行うには、右側または左側のソリューションエクスプローラーでプロジェクトを選択します(おそらく既に選択されているので、これについて心配する必要はありません)。次に、メニューバーのドロップダウンメニューから[プロジェクト]を選択し、[project_nameプロパティ]> [構成プロパティ]> [リンカー]> [システム]を選択します。最初のプロパティであるドロップダウンの「サブシステム」プロパティを「コンソール(/ SUBSYSTEM:CONSOLE)」に設定します。コンソールウィンドウは、実行後に通常どおり開いたままになります。
コードの最後の行にブレークポイントを設定します。
http://social.msdn.Microsoft.com/forums/en-US/Vsexpressvc/thread/1555ce45-8313-4669-a31e-b95b5d28c787/?prof=required からコピーしたばかりです。
以下は私のために働く:-)
////////////////////////////////////////////////// ////////////////////////////////////
コンソールが消える別の理由を次に示します。そして解決策:
新しいVisual Studio 2010では、以下を使用した場合でもこの動作が見られる場合があります。 Ctrl + F5 別名「デバッグなしで開始」。これは、おそらく「Win32コンソールアプリケーション」ではなく「空のプロジェクト」を作成したためです。プロジェクトを「Win32コンソールアプリケーション」として作成する場合、適用されないため、これを無視できます。
古いバージョンでは、「空のプロジェクト」を選択した場合でもデフォルトでコンソールサブシステムになりますが、Visual Studio in2010ではそうではないため、手動で設定する必要があります。これを行うには、右側または左側のソリューションエクスプローラーでプロジェクトを選択します(おそらく既に選択されているので、これについて心配する必要はありません)。
次に、メニューバーのドロップダウンメニューから[プロジェクト]を選択し、[project_nameプロパティ]→[構成プロパティ]→[リンカー]→[システム]を選択します。そして、最初のプロパティ、ドロップダウンの「サブシステム」プロパティを「コンソール(/ SUBSYSTEM:CONSOLE)」に設定します。コンソールウィンドウは、実行後に通常どおり開いたままになります。
////////////////////////////////////////////////// ////////////////////////////////////
コンソールアプリケーションの場合、使用 Ctrl + F5。
Boost.Testには、テストが(例外またはアサーションエラーで)失敗したときにデバッガーに侵入するための--auto_start_dbg
パラメーターがあります。何らかの理由でそれは私のために機能しません。
このため、アサーションの失敗または例外が発生したときにデバッガーに侵入するカスタムtest_observerを作成しました。これは、デバッガーで実行しているデバッグビルドで有効になります。
単体テストEXEファイルのソースファイルの1つに、次のコードを追加しました。
#ifdef _DEBUG
#include <boost/test/framework.hpp>
#include <boost/test/test_observer.hpp>
struct BoostUnitTestCrtBreakpointInDebug: boost::unit_test::test_observer
{
BoostUnitTestCrtBreakpointInDebug()
{
boost::unit_test::framework::register_observer(*this);
}
virtual ~BoostUnitTestCrtBreakpointInDebug()
{
boost::unit_test::framework::deregister_observer(*this);
}
virtual void assertion_result( bool passed /* passed */ )
{
if (!passed)
BreakIfInDebugger();
}
virtual void exception_caught( boost::execution_exception const& )
{
BreakIfInDebugger();
}
void BreakIfInDebugger()
{
if (IsDebuggerPresent())
{
/**
* Hello, I know you are here staring at the debugger :)
*
* If you got here then there is an exception in your unit
* test code. Walk the call stack to find the actual cause.
*/
_CrtDbgBreak();
}
}
};
BOOST_GLOBAL_FIXTURE(BoostUnitTestCrtBreakpointInDebug);
#endif
system("pause")
ハックを使用したくないと言います。何故なの?
notのデバッグ中にプログラムにプロンプトを表示させたくないのであれば、それを回避する方法があります。これは私のために働く:
_void pause () {
system ("pause");
}
int main (int argc, char ** argv) {
// If "launched", then don't let the console close at the end until
// the user has seen the report.
// (See the MSDN ConGUI sample code)
//
do {
HANDLE hConsoleOutput = ::GetStdHandle (STD_OUTPUT_HANDLE);
if (INVALID_HANDLE_VALUE == hConsoleOutput)
break;
CONSOLE_SCREEN_BUFFER_INFO csbi;
if (0 == ::GetConsoleScreenBufferInfo (hConsoleOutput, &csbi))
break;
if (0 != csbi.dwCursorPosition.X)
break;
if (0 != csbi.dwCursorPosition.Y)
break;
if (csbi.dwSize.X <= 0)
break;
if (csbi.dwSize.Y <= 0)
break;
atexit (pause);
} while (0);
_
このコードを、作成中の新しい各コンソールアプリケーションに貼り付けるだけです。プログラムがコマンドウィンドウから実行されている場合、カーソル位置は<0,0>にならず、atexit()
を呼び出しません。デバッガ(任意のデバッガ)から起動された場合、コンソールカーソル位置は<0,0>になり、atexit()
呼び出しが実行されます。
MSDNライブラリにあったサンプルプログラムからアイデアを得ましたが、削除されたと思います。
注:system()ルーチンのMicrosoft Visual Studio実装では、コマンドラインインタープリターを識別するためにCOMSPEC環境変数が必要です。この環境変数がめちゃくちゃになった場合-たとえば、Visual Studioプロジェクトのデバッグプロパティに問題があり、プログラムの起動時に環境変数が適切に渡されない場合-静かに失敗します。
または、boost_testの「ログ出力のテスト」を使用できます。
http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/utf/user-guide/test-output/test-log.html
その後、コンソールウィンドウが表示されるかどうか、およびビルドロギングが失敗したビルドの検査用のアーティファクトとしてユニットテスト出力を保持できるかどうかは関係ありません...
私はあなたが選択した特定の時間(ミリ秒)に「待機」コマンドを使用します。アプリケーションは、検査する行まで実行され、時間が経過した後も継続します。
<time.h>
ヘッダーを含めます。
clock_t wait;
wait = clock();
while (clock() <= (wait + 5000)) // Wait for 5 seconds and then continue
;
wait = 0;
実際にはもっと手間がかかりますが、VS.Netでビルドし、通常のコマンドライン(cmd.exe)から実行し、実行開始後にプロセスにアタッチできます。ただし、これはおそらくあなたが探しているソリューションではありません。
Log4netなどのロギングライブラリを使用し、ファイルアペンダーにログを記録します。
F11でアプリを起動し、unit_test_main.ippのどこかにブレークポイントを取得します(アセンブリコードの場合もあります)。 shift-f11(Step out)を使用して単体テストを実行し、CRTで次のAssembly命令を取得します(通常はmainCRTStartup()で)。 F9を使用して、その命令にブレークポイントを設定します。
次の呼び出しでF5でアプリを起動できます。テストを実行するとアプリが壊れるので、コンソールウィンドウを覗くことができます
外部ツールとして実行可能ファイルをセットアップし、ツールをse output windowとしてマークすることもできます。そうすれば、ツールの出力は、別個のウィンドウではなく、Visual Studio自体の中に表示されます。
次の行を追加すると、メッセージを表示しない単純なMS-DOS pause
が実行されます。
system("pause >nul | set /p \"=\"");
そして、する必要はありません Ctrl+F5 (これにより、アプリケーションがリリースモードで実行されます)