2009-06-01 1 views
3

私はできるだけ多くのロジックをカスタムコントロールから動かすように取り組んでいます。そのため、手動テストの負担を軽減するためにユニットテストを行うことができます。私はテスト中のメソッドが複雑な結果を生成する状況に問題があります。結果を計算するテストケースを書くには、本質的にテスト対象のコードをテスト自体に書き込む必要があります。テスト中のコードを複製する必要があるコードのテストをどのように記述しますか?

たとえば、クラスのプロパティに基づいてWPFジオメトリを作成するGeometryGeneratorクラスがあります。 1つの構成では、ArcSegmentからなるPathGeometryが生成されます。私はアークのプロパティがテストパラメータに基づいているべきものを計算できますが、この計算はテストしようとしているコードと同じです。これは、テストを無効にするように思える。計算にバグがある場合、テストにバグがあり、メソッドの計算が変更された場合、テストで変更する必要があります。

この状況についてはどうすればよいですか?私が思いついた唯一のアプローチは、テストケースの結果を手作業で計算し、これらの値をテストにハードコードすることです。これは受け入れ可能なアプローチですか(実装前にテストを書いていたら、私がやったようなものです)?

答えて

4

唯一のアプローチは、テストケースの結果を手動で計算し、これらの値をテストにハードコードすることです。これは受け入れ可能なアプローチですか(実装前にテストを書いていたら、私がやったようなものです)?

はい、これは一般的です。ユニットテストの目的のために、結果を計算するために使用しているの式が正しいと仮定する必要があります。これは、テストしているソフトウェアの実装です。

手作業で計算した結果をあらかじめ計算しておき、テスト中のコードを使用してテストデータを生成していないことを確認します(ユニットテストでは非常に悪いことです)。テストケースを文書化して、期待値が表すものとその出所を知るようにしてください。

0

「単体テスト」は、単なる単体テストをテストする必要があります。理想的には、あなたのGeometryGeneratorのための別々のユニットテストを持つことになり、別々のユニットのそれぞれをテストすることによりなど

あなたPathGeometryクラス、あなたのArcSegmentための第三のためのもう一つは、あなたは彼らがどのように動作するかについての信頼のいくつかの並べ替えを得ることができます指定された入力セット(ArcSegmentのフィールドが1に設定されている場合のGeometryGeneratorの動作、同じフィールドが0に設定された場合の動作など)を指定して、指定された操作を呼び出します。

ユニットテストで、既存のコードを複製して特定の機能をテストしているように見える場合は、ユニットテストを間違って実行している可能性があります。 。

1

手作業での計算とハードコーディングは実動コードでは悪いが、単体テストには不可欠です。

通常、コードの各「状態」ごとに1つのテストを作成します。たとえば、正の入力、負の入力、ゼロ入力のテストを書いて、コードが期待どおりに機能していることを確認します。

1

一般的に、私は自己文書そのマジックナンバーを作りますが、

のconst int型expectedResult = 2 * 4/someConstantのように、ハードコードされ; //おそらくコメント。

テストの読者は、値が何であるかを推測するか、必要に応じて追加のコメントを追加することができます。