テストの作成方法

私たちのソフトウェアのテストを作成するのはとても良いことです.しかし、実際には、これまで作成されたテストも同様に重要であることがあります.以下の偏った原則を通じて、テストをより完璧に書きましょう.

テストコードをコンパクトに読みやすく保つ

これを行うには、本番コードのように、再構築をためらうことなく行うことがあります.そうでなければ、テスト側で恐ろしい残留コードを作成したように、テスト側で腐ったコードが生成されます.テストが再構築しにくい場合、本番コードも再構築しにくくなり、本番環境に残されたコードが生成されます.勇敢な再構築者になってください.

煩わしいコードを避ける

たとえば、テストコードは、parserで使用されるregexpを複数回使用して何かを生成します.
一般的に、テストとコードの間で論理をコピーしたくない.したがって、テストで本番コードregexpや他のものをコピーするのは良い選択ではありません.この場合、「入力刺激」/「出力結果」のテストを考慮すると、(f(input)->output)に役立ちます.たとえば、あるセグメントのコードが処理テンプレートを仮定している場合、valueを持ち込まないでください.したがって、計算結果に基づいてテストを行ってください.

    // use
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo("this is 'param1', and this is 'param2'"));

// instead of
Assertions.assertThat(processTemplate("param1", "param2")).isEqualTo(String.format("this is '%s', and this is '%s'", param1, param2));

正確で特にエラーのあるコードの状況を示すために、カバー度をできるだけ大きくします。

通常、これはテスト駆動開発を実践する際に最良の実現方法である.TDDがあれば、人々は設計時に何が破壊される可能性があるかを認識することができます.些細なことで簡単なテスト例を書くのを恥じないでください.このコードをいつ、なぜ、またはどのように使用または変更するかは、いつまでもわかりません.
試験の有効性を調べるために使用できる範囲領域の1つの方法は、PITなどのツールを用いて突然変異試験を行うことである.

あなたが持っていないオブジェクトのタイプをmockしないでください。

これは硬い指標線ではありませんが、この線を越えると悪果が出る可能性があります!(おそらく)
TDDはテストと同様に重要であり、外部APIをシミュレートする場合、テストは駆動設計に使用できず、APIは他の人に属する.サードパーティは、APIの署名および動作を変更することができる.

mockサードパーティlibのコードを想像してみてください.3番目のライブラリの特定のアップグレード後、論理はいくつか変化する可能性がありますが、テストキットはシミュレーションされているため、よく実行されています.だからその後、私たちはすべて正常に動作していると思って、私たちはソフトウェアの導入を始めましたが、BOOM、私たちは51 Jobに行かなければならないかもしれません.

これは、サードパーティ製ライブラリとの現在の設計の結合が不十分である可能性がある兆候である.

のもう一つの問題は、サードパーティ製ライブラリが複雑で、正常に動作するには多くのシミュレーションが必要になる可能性があることです.これにより、過剰に指定されたテストおよび複雑なコンポーネントが使用され、テスト自体のコンパクトさおよび可読性の目標が損なわれる.あるいはコードオーバーライドが不十分なテストは,外部システムの複雑さをシミュレートするため,テストのオーバーライドが不十分な問題を引き起こす.

したがって、最も一般的な方法は、抽象的な漏洩のリスクに注意すべきであるが、低レベルのAPI、概念、または異常がパッケージの境界を超えているため、外部lib/システムのパッケージを作成することである.サードパーティ製ライブラリとの統合を検証するために、統合テストを作成し、できるだけコンパクトで読み取り可能にします.
一部の人はすでにこのことを書いたことがあります.mockが彼らが持っていないタイプのとき、彼らの精力的な苦痛を過ごしました.

http://davesquared.net/2011/04/dont-mock-types-you-dont-own.html

http://www.markhneedham.com/blog/2009/12/13/tdd-only-mock-types-you-own

http://blog.8thlight.com/eric-smith/2011/10/27/thats-not-yours.html

http://stackoverflow.com/questions/1906344/should-you-only-mock-types-you-own

すべてをロックしないでください。結局彼は逆モードです。

もしすべてがシミュレーションされていたら、私たちは本当に生産コードをテストしていますか?mockしないときはなるべくmockしないように!

値オブジェクトをシミュレートしない

どうしてそうしたい人がいるの?
実体化対象が辛いから!?=>これは本当に正当な理由ではない.
新しいfixtureを作成するのが難しい場合は、コードに強い再構築が必要になる可能性があります.もう1つの選択肢は、値オブジェクトのコンストラクタを作成することです.IDEプラグイン、Lombok、その他のツールがあります.また、テストクラスパスに意味のあるファクトリメソッドを作成することもできます.fixtureコンセプトはここを参照

abstract class CustomerCreations {
   public static Customer customer_with_a_single_item_in_the_basket() {
       // long init sequence
   }
}

Mockitoはオブジェクト間のインタラクションに注目しており,これはオブジェクト向けプログラミング(またはメッセージ)の最も重要な部分である.

「Growing Object Oriented Software Guide by Tests」を読む

この本は必読です.すべてのアプリケーションから機能的なアプリケーションへの移行方法について説明します.著者らは,開発の多くの側面と,プロジェクトライフサイクルの各段階でテストをどのように実現するかを説明した.