私はアジャイル手法を実践しようとする多くのチームに所属しており、多くの場合、これらのチームはテスト中心です。テストはアジャイル手法を実践するのに必要な部分ですか、それとも長年にわたって定着しているXPの実践ですか？

主にアジャイルは漸進的な改善に基づいているため、テストはアジャイルにとって絶対に不可欠です。困難は、現在の変更が古いコードにどのように影響するかを確認するのが難しい場合があることです。何かを壊していないことを確信する最良の方法は、それをテストし、それをテストする方法を知ることです。そうすれば、古い機能を壊したコードを書いていたときに自分がやったことを忘れてしまったときに、すぐにバグを見つけることができます。

これがより伝統的なトップダウン設計タイプのプログラミングと異なる理由は、その環境では、a）最終製品が完成するまでテストするのが非常に難しいためですb）理論的には、すべての設計基準を同時に検討しそのため、以前の設計決定を破る設計決定を下す可能性が低くなります。

あなたはおそらく自動テスト、単体テスト、統合テストなどについて話しているでしょう。これらは手動テスト（テスターなど）よりもアジャイルにとってより重要です。なぜならそれらは遅すぎるため、小さな変更をすべてテストすることができないからです アジャイルは高速の小さな反復であるため、数時間または数日ではなく、数秒または数分で正確性を検証するテストを持つことは非常に便利です。

テストがない場合、コードが機能することをどのように確認しますか？

編集：コードが機能することをテストで証明できないという主張は、1つの重要な用語、つまりworksを定義できません。プログラムが機能するということはどういう意味ですか？この用語をあいまいにすると、プログラムが機能することを証明したり、確認したりする方法がまったくありません。今まで。

一方、作品を「仕様に従って動作する」と定義できます。これで、テストを使用してコードが機能することを示すことができるだけでなく、テスト自体がコードの動作の実行可能な仕様として機能できます。言い換えれば、うまく書かれたテストスイートは、動作の意味を定義します。

この考え方により、バグの意味を再検討する必要があります。コードがすべてのテストに合格した場合、コードにバグはありません。それにもかかわらず、システムが本来の動作をしない場合、その動作は正しく指定されていません。I. e。バグは仕様にあり、テストで定義されています。

ソフトウェア開発に対するこのアプローチは、システムの機能仕様をその実装から切り離します。これは、世界のすべてのソフトウェアエンジニアリングの本によると、非常に良いことです。同時に、このアプローチにより、実装が常に機能仕様に対応することが保証されます。

いいえ、「必要」ではありません

アジャイルの原則は、テストについて直接言及していません。

しかし、それは非常にお勧めです

持続可能なプロセス、継続的/増分的配信、ソフトウェア品質に対するアジャイルのコミットメントを考えると、自動テストはほとんどのプロジェクトで現在利用可能な最良のソリューションです

例外（JörgW Mittagが述べたように）には、間違いなく正しい開発ツール、コードを生成するメタプログラミングシステムなどが含まれます。しかし、これらの種類のシステムはまれです。

アジャイルとXPの両方が、Big Design Up Frontを避けようとします。BDUFでは、要件が収集され、正式な仕様が作成され、次にコーディングが行われ、次にテストが行​​われます。これは、医療機器、宇宙探査機などのように、明確に定義されたミッションクリティカルなシステムにとって重要です。

アジャイルはこのフローを回避します。これは、「クライアントが今週要求するものは何でも」など、明確に定義されていない問題に対してうまく機能しないためです。まだ正式な仕様が必要なので、何をすべきか、いつ完了したかを知っていますが、何らかの種類の文書ではなく、自動テストの形でコードを使用します。

自動化された単体テストは、作成が迅速で実行が迅速で、非常にモジュール化/分離されています。これにより、要件を正式に指定して確認する迅速な方法になります。