コードのバグやロジックの変更などの理由で実際には一致しない、または機能しなくなった古い単体テストを管理するための最良の方法を理解しようとしていますか？それらをすべてスキップして、現在のロジックに合うように変更しますか？
たとえば、それらのテストがあなたによって書かれていなかった場合、そして今あなたはコードを修正する責任があります。先に進む前に、これらのテストを更新して合格するまで、まだ時間がかかりますか？
または単にそれらをスキップしますか？ありがとう。
7 に答える
3
古いユニットテストは役に立ちません。それらを使用したい場合は、それらを更新してください。
于 2009-02-24T07:54:23.097 に答える
2
もちろん、あなたはそれらを通過させるために時間をかける必要があります。なぜその仕事を捨てるのですか？
TDDの全体的な考え方は、すべてのテストに常に合格することです。「ねえ、この単体テストが失敗しても大丈夫だ」と言い始めた瞬間から、TDDは役に立たない。はい、ある程度の規律が必要ですが、最終的にはそれだけの価値があります。
于 2009-02-24T08:01:52.457 に答える
2
テストが失敗した場合、次の 3 つのオプションがあります。
- 製品コードが壊れており、修正する必要があります。
- テストが壊れている (または、製品コードへの最近の変更で最新でない) ため、テストを修正する必要があります。
- テストで指定された動作は不要になり、テストを削除できます。
新しいコードを記述する前に、すべてのテストに合格する必要があります。テストが失敗した場合は、すぐに修正するか、変更を元に戻す必要があります。そうしないと、テストが失敗したときに、それが 1 分前に行った変更によるものなのか、それとも単なる誤警報なのかを確信できません。
失敗したテストを無視することは、暗黒面への道です。それらを十分に長く無視すると、さらに多くのテストが失敗してテスト スーツが腐敗し、その価値が失われ、テストを破棄する必要があります。そして、テストスイートに頼れなくなったとき、本番コードの設計を改善することを躊躇し、本番コードも腐敗し始めます。最後に、本番コードを維持することはもはや不可能であり、それも破棄して書き直す必要があります。
于 2009-02-24T15:35:14.830 に答える
1
たとえば、それらのテストがあなたによって書かれていなかった場合、そして今あなたはコードを修正する責任があります。先に進む前に、これらのテストを更新して合格するまで、まだ時間がかかりますか？
テストを更新します。
しかし、最初に私はそれらを壊した開発者を追い詰めますそして...まあここにいくつかのインスピレーションがあります。
于 2009-02-24T08:02:53.530 に答える
1
私が同じような状況に陥るたびに、時代遅れのテストは存在しないと思うほど急いでいます。結果として、私はコードをレガシーコードと見なし、作業している機能に対してのみ新しいテストを作成します。
于 2009-02-24T08:11:27.190 に答える
0
テストが失敗することは決して受け入れられません。システムは、すべてのテストに合格しない可能性を拒否する必要があります。または、少なくとも、テストが失敗すると、テストが失敗する原因となった開発者に対する優先作業タスクがトリガーされます。
時間の経過とともに、テストは特に成熟した製品では時代遅れになります。せいぜい、それらは単にコードを実行するのに役立ちます。失敗することもありますが、通常は、そもそもなぜ書かれたのかとは関係のない理由で失敗します。廃止されたテストを破棄するかどうかについては、自分の判断で判断する必要があります。時々枯れ木を切り落とさなければ、テストが完了するのに時間がかかりすぎるので、10,000のテストがあります。
テストカバレッジツールは、特定のテストを維持する価値があるかどうかを判断するのに役立ちます。
于 2009-02-24T15:15:59.167 に答える
0
そこでは、次の 2 つの状況が考えられます。
- 少数のテストが失敗する - テストを修正する
- ほとんどのテストは失敗し、すべてのテストを修正して変更を実装するには、より多くの時間がかかります。テスト プロジェクト全体を削除して、新しいテストを記述します。
于 2009-02-24T08:58:24.613 に答える