コンソール アプリケーションとして実行したい Boost 単体テストのコレクションがあります。
プロジェクトに取り組んでいるときにテストを実行すると、テストをデバッグできるようになり、テストの実行後もコンソールを開いたままにしたいと考えています。
リリース モードで実行すると、プログラムの終了後もコンソール ウィンドウが表示されたままになりますが、デバッグ モードではそうではありません。
「system("pause");」を追加したくない または、プログラムに文字を読み込むなどのその他のハック。リリース モードで実行している場合と同じように、デバッグを使用してテストを実行した後、Visual Studio を一時停止したいだけです。また、テストの出力が Visual Studio の出力ウィンドウの 1 つにキャプチャされた場合も希望しますが、それも必要以上に難しいようです。
これどうやってするの？
Ctrl+のF5組み合わせでアプリケーションを実行してみてください。
古いバージョンでは、「空のプロジェクト」を選択した場合でもデフォルトでコンソール サブシステムになりますが、2010 ではそうではないため、手動で設定する必要があります。これを行うには、右側または左側のソリューション エクスプローラーでプロジェクトを選択します (おそらく既に選択されているので、心配する必要はありません)。次に、メニュー バーのドロップダウン メニューから「プロジェクト」を選択し、「project_nameプロパティ」 > 「構成プロパティ」 > 「リンカ」 > 「システム」を選択して、最初のプロパティであるドロップダウンの「サブシステム」プロパティを「コンソール (/サブシステム:コンソール)". コンソール ウィンドウは、実行後も通常どおり開いたままになります。
Boostテストは、コンパイルの最後に単体テストを自動的に実行し、出力をビルドウィンドウにキャプチャできるようにする、 VisualStudioの次の使用上の推奨事項を提供します。
このトリックの優れた副作用は、テストの失敗をコンパイルエラーとして扱うことができることです。「...コンパイルエラー分析に使用する通常のキーボードショートカット/マウスクリックを使用して、これらのエラーを飛び越えることができます...」
コードの最後の行にブレークポイントを設定します。
以下は私にとってはうまくいきます:-)
/////////////////////////////////////////////// //////////////////////////////////
コンソールが消える別の理由があります。そして解決策：
Ctrl新しい Visual Studio 2010 では、 +F5別名「デバッグなしで開始」を使用した場合でも、この動作が見られる場合があります。これは、「Win32 コンソール アプリケーション」ではなく「空のプロジェクト」を作成したことが原因であると考えられます。プロジェクトを「Win32 コンソール アプリケーション」として作成する場合は、適用されないため無視してかまいません。
古いバージョンでは、「空のプロジェクト」を選択した場合でもデフォルトでコンソール サブシステムになりますが、Visual Studio 2010 ではそうではないため、手動で設定する必要があります。これを行うには、右側または左側のソリューション エクスプローラーでプロジェクトを選択します (おそらく既に選択されているので、心配する必要はありません)。
次に、メニューバーのドロップダウンメニューから「プロジェクト」を選択し、「project_nameプロパティ」→「構成プロパティ」→「リンカー」→「システム」を選択し、最初のプロパティであるドロップダウン「サブシステム」プロパティを「コンソール(/サブシステム:コンソール)". コンソール ウィンドウは、実行後も通常どおり開いたままになります。
/////////////////////////////////////////////// //////////////////////////////////
コンソール アプリケーションの場合は、Ctrl+を使用しますF5。
Boost.Test には--auto_start_dbg、テストが失敗したとき (例外またはアサーションの失敗) にデバッガーに割り込むためのパラメーターがあります。どういうわけか、私にはうまくいきません。
http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/dot-net-specific.htmlを参照してください。
このため、アサーションの失敗または例外が発生したときにデバッガーに割り込むカスタムの 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")あなたはハックを使いたくないと言います。なぜだめですか？
デバッグされていないときにプログラムにプロンプトを表示させたくない場合は、それを回避する方法があります。これは私のために働く：
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 プロジェクトのデバッグ プロパティに問題があり、プログラムの起動時に環境変数が適切に渡されない場合) は、黙って失敗します。 .
あなたが選んだ特定の時間（ミリ秒）の間、「待機」コマンドを使用します。アプリケーションは、検査する行まで実行され、時間切れになった後も続行されます。
<time.h>ヘッダーを含めます。
clock_t wait;
wait = clock();
while (clock() <= (wait + 5000)) // Wait for 5 seconds and then continue
;
wait = 0;
または、boost_test の「テスト ログ出力」を使用することもできます。
http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/utf/user-guide/test-output/test-log.html
次に、コンソール ウィンドウがまったく表示されるかどうかは問題ではありません。また、ビルド ログでは、ユニット テストの出力を、失敗したビルドを調べるためのアーティファクトとして保存できます。
実際にはもっと手間がかかりますが、VS.Net でビルドし、通常のコマンド ライン (cmd.exe) から実行し、実行開始後にプロセスにアタッチすることができます。ただし、これはおそらくあなたが探しているソリューションではありません。
実行可能ファイルを外部ツールとしてセットアップし、そのツールをUse output windowとしてマークすることもできます。そうすれば、ツールの出力は別のウィンドウではなく、Visual Studio 自体に表示されます。
F11 でアプリを起動し、unit_test_main.ipp のどこかにブレークポイントを取得します (アセンブリ コードの場合もあります)。shift-f11 (ステップ アウト) を使用して単体テストを実行し、CRT (通常は mainCRTStartup()) で次のアセンブリ命令を取得します。F9 を使用して、その命令にブレークポイントを設定します。
次の呼び出しで F5 キーを押してアプリを起動すると、テストの実行後にアプリが壊れるので、コンソール ウィンドウをのぞくことができます。
pause次の行を追加すると、メッセージを表示しない単純な MS-DOS が実行されます。
system("pause >nul | set /p \"=\"");
Ctrl+する必要はありませんF5(これにより、アプリケーションがリリース モードで実行されます)。
log4net などのロギング ライブラリを使用して、ファイル アペンダにログを記録するだけです。
最後に readline を実行します (これはコロンビアで言うように "forma cochina" ですが、機能します):
static void Main(string[] args)
{
.
.
.
String temp = Console.ReadLine();
}