SDLC では、テスト手順は実装直後に行う必要があります。ただし、テスト駆動開発では、実装を行いながらテストを行うことが推奨されます。私の講義で教授は、テストケースは設計の一部であるべきだと言いました。
新機能を実装するジュニア開発者ですが、いつテスト ケースを設計して文書化する必要がありますか?
実装を終えた後にすべてのケースをテストするのはあまり現実的ではないことがわかりました。ケースが失敗すると、コードを変更してすべてのケースを再テストする必要があるためです。これを克服して回避する別の方法はありますか？自動化された睾丸が解決策の 1 つであることは知っていますが、どういうわけか、自動化された睾丸はすべてのテスト ケース、特にさまざまな関係者が関与する統合テスト ケースを刺激することはできません。
また、私のテスト ケースでは、コードのすべての部分をテストする必要がありますか? または、その機能リクエストの機能をテストするだけですか? それとも、実際にどれくらいの時間を得たかによって異なりますか?
どうもありがとう。
あなたの質問に答えるのは簡単ではありません。なぜなら、あなたが言うように、「それは実際にどれだけの時間を得たかによる」からです。ただし、いくつかの意見があります。
実装後のテスト: いいえ
プログラマーとして、あなたは高価で希少なリソースであり、複数の締め切りが重なり合っています。事実上、これは「テストしない」ことを意味します。コードの 1 つのチャンクを実装した後、次のコードのチャンクに進み、「時間があれば」テストを書きに戻ることを意味します (時間がありません)。
ご指摘の問題もあります。コードを書いた後にすべてのテストを行い、そのテストで何か根本的な問題が見つかった場合は、戻ってすべてのコードとすべてのテストを修正する必要があります。
実装中のテスト: はい
この方法は、リズムをつかむと実際に非常に役立ちます。クラスを少し書き、次に単体テストを少し書き、完了するまでテストとコードを継続的に修正します。実際、テストなしでコードを書くよりも速いと思います。
また、大規模なプロジェクトで作業する場合にも特に役立ちます。単体テストを実行して、小さなモジュールが機能しているかどうかを確認するのは瞬時です。アプリケーション全体をビルドしてロードして、小さなモジュールが機能しているかどうかを確認するには、数分かかる場合があります。また、集中力が途切れる可能性もあります (少なくとも 10 分かかります)。
何をテストするか: 可能な限り
100% のテスト カバレッジはおそらく実用的ではありません。ただし、プログラムの重要な部分、つまり数学的計算や多くのビジネス ロジックを実行するものは絶対にテストしてください。残っているものはすべて可能な限りテストします。「toString()」関数をテストする理由はありません。ただし、それがビジネス ロジックなどにとって非常に重要な場合を除きます。
また、入力と出力だけで、テストをできるだけシンプルに保ちます。テスト関数のほとんどは 2 行または 3 行です。組み合わせが多すぎて関数のテストが難しい場合は、関数を少し分割する必要がある可能性があることを示しています。エッジケースと「不可能」なシナリオを必ずテストしてください。
私の経験：
それとも、実際にどれだけの時間を得たかによって異なりますか?
テストを行わないことで節約できる時間は、プロジェクトの後半でバグを解決するために費やさなければならない時間の代償にはなりません。適切なテスト セットは、常に多くの利益をもたらします。