開発後のテストの落とし穴は何ですか？

Question

最近、すでに途中にあったプロジェクトに割り当てられました。それはTDD環境でした。 誰もがコードユニットテストファーストとインプリメンテーションコードの正しい原則に従っていました。しかし、カップルは逆順で実装コードを最初に実行し、ユニットテストは後で行いました。

討論の結果、彼らはどちらかといえばその類似点を言います。

インプリメンテーションコードを最初に実行して後でユニットテストを実行すると、どのような問題が発生する可能性がありますか？

Answer 1

• 実際のところより多くのコードを記述している可能性があります。
• バイアス - 要件ではなく実装をテストするテストを書くことができます。
• テストではデザインが改善されません。テストではデザインの改善が示されます。時間が経つにつれて、あなたのデザインは厳しくなり、変化を嫌うでしょう。
• あなたの実装には、テストを書くときにのみ現れるテスト容易性の問題があるかもしれません。今度はテストが次の機能を実装するためにあなたの方法で立っているので、あなたは何かを突っ込んでしまう傾向があります。テストできないブロブを単体テストしようとすると、イライラすることがあります。より多くの場合、完全ではないテスト（簡単に何が起こっているかをテストします）に終わるでしょう。
• テストが書かれていない可能性があります。実装が準備完了し、手動で動作確認を行ったら、ボーリングユニットテストをスキップして興味深い部分にスキップする傾向があります。時間の経過とともに、未検証の混乱。

明らかに不明な点がある場合は、テスト初のFTW！

Answer 2

最初にテストを作成し、afterを実装することで、確実にテストに合格する実装コードを記述することができます。最初に実装し、テストコードを記述した後には、正確なテスト範囲を確保するために実装コードをリファクタリング（時には大幅に）する必要があるという固有のリスクがあります。

個人的な経験では、開発者が実装と並行してテストを行い、インターフェイス契約の境界が正しくロックされ、テストにふさわしいことを確実にするために十分な前向きな作業を行っています。最終的に再設計/主要なリファクタリングを引き起こさないが、ユニットテストの完全なセットが提供されるまでコンポーネントを完了していないテスト。

Answer 3

実装前のテストは常に推奨されます。あなたのソフトウェアに存在していた可能性があるバグを実際に修正することを除けば、エンジニアが「コードを超える」傾向を持つ可能性があるため、コードのどの部分が必要なのかを取り除くのに役立ちます。

「私が飛行機のオートパイロット用のソフトウェアを作っていたら、そのソフトウェアがにならないと確信するために私は何をしますか？は失敗しますか？これらの人々はソフトウェアをテストする前に逆にそれをやって、オートパイロットに家族を置くだろうか？このように考えることで、ソフトウェア工学に対する規律あるアプローチが可能になります。