単体テスト初心者向けの単体テストのベストプラクティス

近年、私は大規模なプロジェクトや小さなツールの人々のために小さなコンポーネントのみを作成しました。私はユニットテストを書いたことがなく、常にそれらの書き方を学び、実際にユニットテストを作成するのは、単にプログラムを起動して実際にテストするよりもはるかに時間がかかります。

私はちょうど完了するのに数か月かかる可能性があるかなり大規模なプロジェクトを開始しようとしていますが、（いつものように）書いているときに要素をテストしようとしていますが、ユニットテストで時間を節約できるかどうか疑問に思っています。

誰かが良いアドバイスをすることができるかどうか疑問に思っていました：

1. プロジェクトの開始時に単体テストを検討し、TDDアプローチを採用する可能性があります。
2. 各セクションが完了した後、テストを書くだけです。
3. プロジェクトを完了し、最後に単体テストを作成する必要があります。

そうでないと言う人もいますが、TDDと単体テストを分離することをお勧めします。TDDは非常に精神的な変化であり、ユニットテストには最初は時間がかかるようです。それらを1つのアイテムと見なすと、すぐに十分な利益が得られないリスクがあり、TDDと単体テストを単純に削除したくなる誘惑があります。

最初のことは、いくつかの単体テストを書くことです。最初は完璧である必要はありません。コードの小さな単位をテストする方法と、コンポーネントを分離するためにモックを使用する方法を自分で学んでください。

これは最大の時間を要しますが、最大の見返りがあります。テストするページにアクセスするために14のWebページをページ移動する必要がなくなったことに気づいたら、私が何を話しているのかがわかります。

私にとって、大きなユーレカの瞬間はWindowsアプリで、正規表現をテストしようとしていたため、2つのフォームに入力する必要がありました。NUnitをインストールし、そのメソッドに関するテストを作成して、テスト時間をどれだけ短縮できるかを確認しました。次に、エッジケースに対処するためのテストを追加しました。等々。

次に、ユニットテストを適切に作成する方法を学びます。書くのが速い脆性テストと多くの個々のテストを書くことのバランスを学びましょう。これはかなり簡単です。理想的には、各テストは1つのことだけをテストしますが、どれくらい時間がかかるかをすぐに理解できるので、コードの変更ごとに中断するテストを作成するまでルールを少し曲げてから、適切なバランスに戻ります。 （後者より前者に近い）。

TDDは、私が言ったように、仕事のやり方の大きな精神的な変化です。ただし、とにかくテストをすでに作成していれば、開発プロセスにそれほど時間はかかりません。そして、あなたはまさにあなたの目の前であなたのコーディングスタイルが改善するのを見るでしょう。むしろ、もしあなたがそれを落とさないなら、それはあなたのためではありません。

最後に留意すべきことは、TDDは単体テストに限定されないということです。受入テスト駆動設計は、TDDの一部です。あなたの心の中でそれらを混同しない別の正当な理由。

私は他の人に同意します（最後にテストを書くことは絶対にしないでください。TDDは学習するのに時間がかかりますが、テストを始められますが、最終的には完全なTDDを目指します）。しかし、私はあなたのコメントに応えて、「単体テストで時間を節約できるかどうか疑問に思っています」と付け加えました。

私の答えは明確です。10年ほど前に、テストなしで同様の時間コーディングを行った後、TDDアプローチを学びました。最近、私が何か短い（250 loc未満）でシンプルなことをしたり、何かを捨てたりするのであれば、TDDはしません。そうでなければ、私はそうします、そしてそれは正確に時間を節約するからです。

時間の節約には、WTFの削減、デバッグの削減、恐怖の削減という3つの方法があります。1つ目は明らかです。自分が構築したものが一体何をしているのかを考える時間を大幅に短縮できます。問題が発生した場合、a）テスト済みのバグを即座にキャッチし、b）テストされていないバグを隠す場所が少ないため、デバッグがはるかに簡単になります。

しかし、恐れが少ないほど、それはより微妙です。TDDコードベースでしばらく時間を費やすまでは、自分が行っている変更について心配するのにどれだけの時間を費やしているのかさえ理解できません。Xは動作しますか？Yを壊しますか？影響を受ける可能性のあるZがありますか？TDDを使用すると、恐怖がテストに変わり、コンピューターが心配を自動化するため、それはなくなります。勇敢な開発者は、より速い開発者です。

1. 最初にユニットを見て、TDDアプローチを採用する必要があります。

2. 各セクションが完了したら、テストを書くだけです。

これらのいずれかですが、3番目のオプションではありません。

@pdrが指摘したように、適切な単体テストの学習には時間がかかります。締め切りが迫っている終わりに向かってではなく、プロジェクトのライフサイクルの初めに時間をかけて学習することは間違いありません。これにより、プロジェクトのライフサイクルの早い段階でほとんどのバグをキャッチしたため、すでにスピードアップしており、締め切りが近づくまでにメリットを享受できます。

特にすでに作成されたコードをテストする場合は、最初の単体テストが常に最も難しいことに注意してください。このようなコードは単体テストに対応していない可能性があるため、すべてのオブジェクトをテストの適切な状態に接続するのに苦労する場合があります。したがって、最初の単体テストの試みのために、簡単でかなり孤立した低レベルのテストをいくつか選択し、その後、徐々にチャレンジのレベルを上げることができます。最初のテストフィクスチャの準備ができたら、次のテストケースの方がはるかに簡単です。4番目のテストケースに到達するまでに、コンベアベルトのようなテストケースを作成します。それは、あなたがコードが機能することを繰り返し、実証的に証明できることの良さを感じ始めるときです...

私は個人的にTDDアプローチを好んでおり、それほど難しいとは思いません-忍耐が必要ですが、TDDを開始するのが早ければ早いほど、ユニットテスト全体の利点がすぐにわかると思います。ただし、最初の数個の単体テストは、すでにお持ちのコード用に作成した方がよい場合があります。その後、いったん慣れると、TDDの実験を開始できます。

初心者にとって最善の方法は、単体テストに役立つコードカタに取り組むことだと思います。例えば; 電子メールアドレスの検証。これらのコードカタスのいくつかに取り組むと、TDDは自然な流れになります。前述の電子メールアドレス検証ツールについては、次のコードカタを確認してください。電子メール検証 ツール

コードカタスがわからない人のためのものであるという説明については、次のリンクをチェックしてください： コードカタス