問題タブ [testability]

System.exit()特定の入力に対して呼び出すメソッドがいくつかあります。残念ながら、これらのケースをテストすると、JUnit が終了します。System.exit()現在のスレッドだけでなく JVM も終了するため、メソッド呼び出しを新しいスレッドに配置しても効果がないようです。これに対処するための一般的なパターンはありますか? たとえば、スタブを代用できSystem.exit()ますか?

[編集] 問題のクラスは、実際には JUnit 内でテストしようとしているコマンドライン ツールです。もしかしたら、JUnit は単にこの仕事に適したツールではないのでしょうか? 補完的な回帰テスト ツールの提案を歓迎します (できれば、JUnit および EclEmma とうまく統合されるもの)。

「強化された」コンボ ボックスの望ましい機能は、クイック検索メソッドです。コンボボックスの各項目には ToString() メソッドがあり、ドロップダウン リストに表示できます。ドロップダウン リストの項目をクリックすると、コンボボックスのオブザーバーに選択が通知されます。

また、コンボボックスに入力されたテキストが変更されるたびに、それまでに入力されたテキストを含むドロップダウン リスト内のすべての項目で構成される「候補」のリストが生成されます。Enter キーを押すと、そのリストの最初の候補に移動し、Enter キーを繰り返し押すと、リストが循環します。

私は ComboBox から派生してこの機能を実装しました - 機能的にはまだコンボボックスが残っているので、これは理にかなっていると思いました.この「QuickFind」機能が追加されているだけです. ただし、候補リストを作成して循環させるロジックは単純ではありますが、完全に自明というわけではないため、いくつかのテストが必要です。

ただし、ここに示すように、ComboBox を作成して、追加した追加のルーチンを実行するだけでは、ComboBox をテストするのはそれほど簡単ではないようです。同じように動作するには、フォーム上に存在する必要があります。アプリケーションで。これは、単純なコンボ ボックスへの単純な追加をテストするには、かなりの労力を要します。

ただし、候補を循環するコードは私のアプリケーションに固有のものではありません。任意の数のコンテキストで使用できる一般的なコントロールを作成しました。唯一の要件は、コンボボックス内のオブジェクトに ToString() メソッドがあることです。とにかく、通常のコンボボックスに入るオブジェクトに課されるのと同じ制限であり、C# .NET によって保証されています。

では、テスト容易性を念頭に置いて、強化された機能をどこに配置しますか?

オブジェクトを設計しているときに、テスト容易性の観点からはコンポジションがより良い選択であることがわかりました。その理由は、単体テストの実行中に、必要に応じて構成構造の一部をモックできるからです。継承階層がある場合、これは不可能です。

他の人もこれが構成を好む理由であるとわかっているかどうか知りたい. また、継承が使用されたために、他にどのようなテスト容易性の落とし穴に陥りましたか?

ライブラリの「コア」セットの作成を担当する誰かが、ロギング、監査、および一般的なデータベースアクセスメソッドからのあらゆる種類のユーティリティを提供する静的クラスのセットを作成しました。

個人的には、これらのクラスをモック/スタブしたり、コンストラクターにインジェクションしたりできないため、テストが難しいライブラリのコアセットがあるため、これは悪臭を放つと思います。

TypeMockを使用してこれらをスタブ化できると思いますが、無料で実行したいと思います。

どう思いますか？

編集

それらをテストするのが難しいと思わない場合は、それらをテストする方法の例を挙げてください。これらの静的クラスは、他の型をインスタンス化してそれらの機能を実行します。

全て、

これについていくつか考えてみたいと思います。最近、私は設計/開発の際に「純粋主義者」の DI/IOC 原則のサブスクライバーになりつつあります。これの一部 (大部分) には、クラス間の結合がほとんどないこと、およびそれらの依存関係がコンストラクターを介して解決されることを確認することが含まれます (これを管理する方法は確かに他にもありますが、アイデアはわかります)。

私の基本的な前提は、拡張メソッドが DI/IOC の原則に違反しているということです。

データベーステーブルに挿入された文字列が適切なサイズに切り捨てられるようにするために使用する次の拡張メソッドを作成しました。

次に、次のように別のクラス内から文字列を呼び出すことができます。

拡張メソッドを使用せずにこれを公正に翻訳すると、次のようになります。

上記の例のいずれかを使用するクラスは、TruncateToSize メソッドを含むクラスとは別にテストできませんでした (TypeMock は別として)。拡張メソッドを使用しておらず、静的な依存関係を作成したくない場合は、次のようになります。

最後の例では、_stringUtil の依存関係がコンストラクターによって解決され、実際の TruncateToSize メソッドのクラスに依存せずにクラスをテストできます (簡単にモックできます)。

私の見解では、最初の 2 つの例は静的な依存関係 (1 つは明示的、もう 1 つは非表示) に依存していますが、2 番目の例は依存関係を逆転させ、結合を減らし、テスト容易性を高めています。

では、拡張メソッドの使用は DI/IOC の原則に反しますか? IOC 方法論のサブスクライバーである場合、拡張メソッドの使用を避けますか?

次のようなクラスがあります。

基本的に、指定された時間が経過した後にタイムアウトが発生するかどうかを確認するための単体テストを作成します。もちろん、テストを実行するたびに10分待つ必要はありません。これを念頭に置いて、私の質問は次のとおりです。

この値を管理して、テストでは10秒、本番環境では10分になるようにするにはどうすればよいでしょうか。これを行うには多くの明白な方法がありますが、私は最もクリーンな方法が何であるかを判断しようとしています。これをプロパティとして公開する必要がありますか？コンストラクターパラメーターとして含めますか？メソッドパラメータとして含めますか？コンパイラ指令を使用しますか？

データベースにアクセスするメソッドを含む、大規模なレガシー コードベースのファイルがあります。クラスは使用されず、メソッド宣言を含むヘッダー ファイルと実装を含むソース ファイルのみが使用されます。

これらのメソッドをオーバーライドして、単体テスト中に DB アクセスを排除したいと考えています。

次のオプションを考えました。

1. ファイルをクラスにしてメソッドをオーバーライドします。
   ここでの主な欠点は、コードベース全体に多くの変更が加えられることです。
   コードは改善されますが、理想的ではありません...
2. ソース ファイル全体#ifdef PRODUCTION_CODEを でラップし、スタブを含む新しいソース ファイルを作成し、反対の方法でラップします。つまり、全体をコンパイルに依存させます。ここでの問題は、回帰テストを実行するビルド システムでは、アプリを作成して回帰テストを行うために 1 回、単体テストの実行可能ファイルを作成するために 2 回コンパイルする必要があることです。

これを行うための推奨される方法はありますか?

テストを簡単にするためにコードを設計する必要がありますか？もしそうなら、テストしやすいようにC++コードを設計する方法。

• C ++で依存性注入をどのように適用しますか？
• 偽のテストオブジェクトの作成を簡素化するために、ベースとして純粋なインターフェイスクラスを使用してクラスを実装する必要がありますか？
  • それは私にたくさんの仮想メソッドを作ることを強いるでしょう。それはパフォーマンスに影響しますか？
• C ++での妥当性を設計するとき、他に何を考えるべきですか？

私はこのコードを持っていますが（おそらくSwingコードであることは無視できます）、通常、コンストラクターの引数が多すぎます。モデルBeanクラスを使用してから、そのオブジェクトをコンストラクターに渡す必要がありますか？

このコードでは、このクラスで使用されるオブジェクトをさらに追加することを検討しています。引数を追加し続けて、コンストラクターに渡しますか？おそらく設定インジェクションを使用しますか？

しかし、ミスコによれば、これはコードの臭いでもあります。

http://misko.hevery.com/code-reviewers-guide/

「オブジェクトは渡されますが、直接使用されることはありません（他のオブジェクトへのアクセスを取得するためにのみ使用されます）」

テスト容易性ブログを持っているMiskoHeveryによると。開発者は、「ホルダー」、「コンテキスト」、および「キッチンシンク」オブジェクトを避ける必要があります（これらは他のあらゆる種類のオブジェクトを取得し、共同作業者のバッグです）。そのオブジェクトのホルダーではなく、パラメーターとして必要な特定のオブジェクトを渡します。

ブローの例では、このコードは臭いですか？必要なパラメーターのみを渡すか、必要なデータを含むモデル/Beanを渡す必要があります。

たとえば、次のようなことをしますか？注。おそらく、コンストラクター引数としてデータを渡すことができたはずです。これはコードの臭いですか？

別の質問：テスト可能なコードを書くことで、あなたはあまりにも多くのクラスを書く傾向がありますか？クラスが多すぎるのか、メソッドが多すぎる1つのクラスがあるのは間違っていますか。クラスは便利で、単一の目的があります。しかし、どこでそれらを1つの大きなクラスにリファクタリングできるかはわかりました...しかし、そのクラスには複数の目的があります。