明らかな出力やデータの変更がないユニットテスト機能

Question

また、私のアプリケーションの単体テストを試してみました。しばらくすると、私は実際に好きではないパターンのコードを見つけました。

今私は「ifThisThanThat」のユニットテストの命名規則を使用していますが、私のテストのあまりにも多くのようなものになってしまった：「ifPassWrongDataThenNoError」、と私は、これらの「ThenNoError」ものの、あまりにも多くを持っています。

一方では、間違ったデータで疑わしいケースをすべてテストし、奇妙な方法で何かを呼びたいのですが、一方、それらのコールはすべて外部に何も変えず、サイド情報も与えません何かが間違っていた場合のエラーを除いて。

何度か、 "... ThenThrowsError"と反対になるかもしれませんが、それでも正しいデザインではないかと思います。いくつかの場合、getterのような関数でオープンしたくないものの中に、UIやオブジェクト内に囲まれたデータと通信するメソッドがあります。

私はちょうどcuriouseだと私はそれらを見て感じるようにそれらのテストを変更する必要があります...より伝統的な感じですか？彼らは良いか悪いのですか？すべてのユニットテスト機能でアサートチェックを使用していないときは真剣に、私は気分がいいとは言えません。

UIの例：リストに要素を追加してステージ上に描画しますが、NULL /間違った要素を追加するときにその関数がエラーをスローしないことを確認しています。誰かに与える理由がないので、オブジェクトからリストを取得する方法はありません。新しい要素を受け入れ、他の要素と一緒に描画します。

Answer 1

[OK]を、明らかに、ほとんどの場合、フィードバックの任意のタイプを取得するチャンスがあります、他のケースでは私はテストのための少なくとも少し特別な情報を開くことができます。

UIの例では、新しいリストのレンダリングから取得したイベントを使用したり、何もチェックしていない場合にレンダリングイベントを取得しないというタイムアウトを待っています。これらすべてが、テストの実行時間を増やします。

タイムアウトを避けるために、ビューオブジェクトをモックし、レンダリング/検証機能が呼び出されたかどうかを直接チェックします。