1

私には方法がありCreateTask(UserId)ます。

このメソッドでは、空または無効な値UserIdに対してチェックするだけで十分ですか?null

Taskまたは、特定の用に作成されているかどうかを確認する必要がありUserIdますか?

また、作成されたタスクの数とその日時も確認する必要がありますか?

4

2 に答える 2

1

これに答えるのに十分な情報がここにあるとは思いません。しかし、あなたのポイントのいくつかに対処します：

このメソッドでは、 UserId null または空で無効な Id をチェックするのに十分ですか?

メソッド自体は内部的にそれを行うことができますが、それはテストの一部ではありません。これは、実行時にエラー チェックを行うメソッドにすぎません。これは、「防御的プログラミング」と呼ばれることがよくあります。

または、特定の UserId に対して Task が作成されているかどうかを確認する必要がありますか?

ここが曇ります。そして、ここで少し離れて全体像を見てみましょう。単体テストを実装ロジックと密結合していないことを確認してください。テストでは、実装を意識せずにビジネス ロジックを検証する必要があります。

「タスクの作成」はビジネス ロジックではなく、単なる実装の詳細である可能性が高いです。テストする必要があるのは、ステップ A を実行すると、結果 B が観察されることです。システムが結果 B を生成する方法は、本質的にテストされているものですが、直接的または明示的ではありません。

単体テストをこのように高レベルに維持する大きな理由は、実装の詳細が変更された場合に、テストを変更する必要がないようにするためです。テスト自体も変更されるため、変更に多くの作業が追加されるだけでなく、変更の検証ポイントとしてのテストが排除されるため、これらのテストの価値が大幅に低下します。テストは、コードの検証に使用される一連のルールとして機能する、かなり単純で静的なものでなければなりません。テストが複雑で頻繁に変更される場合、コードの検証に必要なレベルの信頼が失われます。

すべてのメソッドをテストする必要はありません。システムが実行する観察可能なすべてのビジネス アクションをテストする必要があります。この結果、これらのアクションを実行するメソッドがテストされます。これらのアクションを実行しないメソッドは、そもそもそれらが必要かどうかについて疑問があります。これを判断するには、コード カバレッジ ツールが最適です。

たとえば、MethodA()どのテストでも使用されない which があるとします。これは単なる実装の詳細であり、テストはそれについて知る必要がないため、テストで直接呼び出すことはありません。(この場合、メソッドをプライベートにするか、他の方法で外部呼び出しコードから隠蔽することが理にかなっている場合もあります。) これにより、次の 2 つのオプションが残されます。

  1. MethodA()テストされていないビジネス プロセスで必要とされるため、テストは不完全です。そのビジネス プロセスのテストを追加します。
  2. テストは完了しMethodA()ており、システムでは実際には必要ありません。それを除く。

ビジネス ロジックの全体像に関係なく、テストですべてのメソッドをやみくもにテストする場合、システムが何かを必要としない時期を判断することはできません。また、不要になったコードを非推奨にすることは、シンプルで保守可能なコードベースを維持する上で非常に重要です。

于 2013-10-22T09:58:06.317 に答える
0

1) 単体テストが容易になるように、メソッドを短くシンプルに保ちます (ところで、TDDが優れた設計を推奨する理由の 1 つです) 。

2）すべての境界条件（無効な入力、些細な入力など）を確認します（ところで、TDDを簡単にする方法の1つ）

3）可能なすべてのシナリオをチェックして、高いカバレッジを達成します（これを達成するための最も単純な入力を使用して、可能なすべての実行フローがメソッドを通過します）（ところで、TDDが機能する理由の1つ）

4) メソッドの典型的な使用法を示す実際のデータを使用して、いくつかの (おそらく 1 つの) 典型的なシナリオを確認します。

お気づきかもしれませんが、「既存のメソッドのテスト」の問題を心配する必要がないように、TDDの使用を検討してください :)

于 2013-10-22T09:52:59.890 に答える