9

シンプルなコンソールアプリがあります。通常のメインで起動され、プログラム全体がメインに格納されます。コマンド ライン パーサー ライブラリを使用します。次に、アプリケーションの単体テストを含むソリューションに 2 番目のプロジェクトを作成します。しかし、テストからメインプログラムのプロセスを開始する良い方法が見つからないようです。実際にプロセスを開始するための私の現在のコードは、次のようになります。

...

process = new Process();
process.StartInfo.FileName = "FooBar";
process.StartInfo.Arguments = arguments;

// use it to start from testing environment
process.StartInfo.UseShellExecute = false;

// redirect outputs to have it in testing console
process.StartInfo.RedirectStandardOutput = true;
process.StartInfo.RedirectStandardError = true;

...

設定してみました

process.StartInfo.WorkingDirectory

AppDomain.CurrentDomain.BaseDirectory

Environment.CurrentDirectory;

しかし、コンソール アプリケーションの実行可能ファイルの相対パス全体を指定する必要がありますか?それとも、「テスト済み」アプリケーションのプロセスを開始する洗練された方法はありますか? 最初に、「メイン」プログラムのクラスとしてテストを行った後、問題なく動作しました。テストを独自のプロジェクトに移動したときに問題が発生しました。だからこそ、パスが問題であるか、そのような性質のものであると私は疑っています。

私も Running Program.Main を試しましたが、それはとても間違っているように感じます:)

4

2 に答える 2

21

アプリケーションを次のように再構築することをお勧めします。

  • Program- 引数を解析してSettingsインスタンスを作成するエントリ ポイント
  • Settings- アプリケーションの設定 (好みに合わせて名前を変更)
  • BusinessClassSettings- (間違いなく名前を変更してください!)インスタンスを受け入れる実際の作業

これで、個別にテストできます。

  • への解析をテストしますSettings。つまり、パーサー ライブラリを正しく使用していますか
  • 単体テストが適切なインスタンスを作成するビジネス ロジックSettings

可能であれば、ビジネス ロジックを別のクラスに分けて、もちろん個別の懸念事項に対応させ、それぞれを個別にテストする必要があります。ここで具体的な提案をするのに十分な知識はありません。

于 2012-08-24T12:48:16.473 に答える
2

Program.Main の実行がなぜあなたにとって間違っていると感じるのか、私にはわかりません。
コンソール メカニズムの単体テストを行うべきではありません。この方法で簡単に実行できるプログラムのロジックのみをテストしてください。

于 2012-08-24T07:02:17.100 に答える