5

単体テストの実装方法は理解していますが、それらをいつ使用するかを理解するのに苦労しています。

基本的なリマインダー アプリがあるとします。ユーザーはリマインダーを追加/編集/削除し、それらをテーブルビューで表示できます。アプリのどの部分に対して単体テストを設定する必要がありますか?

4

4 に答える 4

6

理想的な世界の答えは、あなたが書いたコードのすべての行がユニットテストされるべきであると言うでしょう。

しかし、それを少し忘れて、現実の世界に戻りましょう。重要であり、別の防御線を持つことは価値のあるコードのテストを作成します。言い換えれば、1つのフィールドに値を割り当てるだけのコンストラクターをテストすることは非常に理にかなっていますか？ほとんどの場合、そうではありません。クライアントが提供する複雑なXMLからアカウントデータを抽出する単体テストパーサーを使用する価値はありますか？おそらくそうだ。

この違いはどこから来るのですか？2つの主な理由：

  • コンストラクターコードが予測できない変更に苦しむ可能性は低くなります（要件/最適化/リファクタリングの変更に対応するために大幅に進化しているパーサーコードと比較して）
  • コンストラクターコードはかなり単純で、すでに何度もそのようなコードを書いているので、テストは問題を見つけるのに大きな利点を提供しないかもしれません。そのようなコードを一目見れば、何が起こっているのかがわかるでしょう（複雑なXMLパーサーコードと比較して）

なぜ区別するのですか？なぜこれをテストし、それをテストしないのですか？（理想的な世界の答えが示唆するように）単純にすべてをテストする方が簡単ではないでしょうか？

いいえ。時間とお金の制約のためです。コードを書くには両方が必要です。そして、誰かがあなたの製品の配達を待つのに一定の時間しかないと同じように、誰かがあなたの製品に喜んで支払うのは一定の金額だけです。一部のテストは、それだけの価値がありません（ここでも、コンストラクターのコード例）。単体テストは 収穫逓減の影響を受けないことを忘れないでください（80％のコードベースをテストでカバーすると、開発時間が20％余分にかかり、後でデバッグ/メンテナンスにかかる時間を20％節約できますが、さらに10％を実行すると、2倍の時間がかかる可能性がありますそれでも、はるかに少ないゲインが得られます）。

繰り返しになりますが、おそらく「どこに線がありますか？」と尋ねたいと思うでしょう。「わかりました。このコードの単体テストは実際には必要ありません」と決めるのはいつですか。残念ながら、この種の判断には経験が伴います。コードを書き、コードを読み、他の人（おそらくより経験豊富な開発者）が何をして学ぶかを見てください。

いくつかの一般的なアドバイス（ユニットテストの対象）を与えるとすると、それらは次のようになります。

  • ビジネス/ドメインロジックコードから始める
  • 必ずすべての種類のコンバーター/パーサー/計算機をテストしてください（これらはテストがかなり簡単で、頻繁に変更される傾向があり（要件の変更またはリファクタリングのいずれかにより）、その性質上エラーが発生しやすくなります）
  • 単純なワンライナーメソッドのテストは避けてください。ただし、その1行が何らかの形で重要である場合を除きます。
  • 発見したバグのテストを作成します（そしてそれらを保持します！）
  • 「良いコードは99.99％のテストカバレッジが必要」という魔法のおとぎ話に盲目的に従わないでください
  • Programmers.stackexchange.comでトピックに関する質問 を読むと、問題に取り組むためのさまざまな視点が得られることがよくあります。
于 2012-10-03T19:31:19.593 に答える
1

リマインダーをどこかに、おそらく plist に保存していると仮定します。Reminder オブジェクトを生成して格納し、データを取得して、最終的に使用可能な Reminder クラス オブジェクトを生成する単体テストを作成できます。

そうすれば、いくつかのことがわかります。

A: リマインダーの生成は機能しています

B: データを保存する方法は機能しています

C: Data から Reminder オブジェクトへの移動は機能しています

ただし、アプリの実際の「機能」を単体テストできると期待するべきではありません。タッチ イベントやナビゲーション コントロールなど。これらは、まったく別の議論である受け入れテストに任せるべきです。

于 2012-10-03T19:01:08.753 に答える
1

書いたすべてのコードをテストします。本当にかっこよくなりたいなら、まずテストを書いてください。モデルまたはコントローラーにメソッドがある場合は、そのテストも必要です。

コードについて詳しく知らなければ、アドバイスするのは難しいです。しかし、コントローラー ( などRemindersController) とモデル ( などReminder) があるように思えます。これは、私が始める基本的な概要です。

  • リマインダーコントローラー

    • 新しいリマインダーを追加する必要があります
    • 既存のリマインダーを更新する必要があります
    • 既存のリマインダーを削除する必要があります

  • リマインダー

    • initWithMessage:atTime:メッセージを設定する必要があります
    • initWithMessage:atTime:時間を設定する必要があります
于 2012-10-03T19:04:03.663 に答える
0

どのタイプのテストをいつ作成するかを選択する際には、次の原則に従います。

  • エンドツーエンドのテストを書くことに集中してください。単体テストよりもテストごとにより多くのコードをカバーするため、費用対効果の高いテストを得ることができます。これらをシステム全体の基本的な自動検証にします。

  • 複雑なロジックのナゲットに関する単体テストの記述にドロップダウンします。単体テストは、エンド ツー エンド テストのデバッグが困難な場合や、適切なコード カバレッジのために記述するのが面倒な場合に役立ちます。

  • テスト対象の API が安定するまで待ってから、いずれかのタイプのテストを作成してください。実装とテストの両方をリファクタリングする必要はありません。

Rob Ashton がこのトピックに関するすばらしい記事を書いています。私はこの記事を参考にして、上記の原則を明確に説明しました。

于 2013-03-22T13:29:41.507 に答える