仕様を例示する

2004年3月18日

テスト

要求分析

2002年にXP/Agile Universeのワークショップに参加していたとき、「仕様を例示する」というフレーズが、XPにおけるテストの役割の一つを表すのにふさわしいと感じました。

(最近では、テスト駆動開発（TDD）がテストと何か関係があると言うことは非常に時代遅れですが、Jonのように、包括的な自動テストスイートを持つことは「副作用」という言葉が意味するよりも価値があると思っています。たとえば、山登りをすれば100万ドルもらえるとしたら、山登りの主な目的は自然を楽しむことだと言うかもしれませんが、私の財布への副作用は決して些細なものではありません...)

仕様を例示するという考え方は、私たちが仕様について考えるように教えられてきた方法とは異なります。仕様は、すべてのケースをカバーするように、一般的に記述されるべきものです。例はいくつかのポイントを強調するだけで、自分で一般化を推測する必要があります。これは、仕様を例示することが唯一の要件定義手法ではないことを意味しますが、主導的な役割を担えないことを意味するものではありません。

これまでの厳密な仕様（合格または不合格が明確に判断できる仕様）の主流な考え方は、事前条件と事後条件を使用することでした。これらの手法は形式手法で主流であり、契約による設計の基礎にもなっています。これらの手法にはそれなりの場所がありますが、理想的ではありません。事前・事後条件は、状況によっては非常に簡単に記述できますが、非常に難しい場合もあります。私はエンタープライズアプリケーションの設定でこれらを試してみましたが、多くの状況では、事前・事後条件を記述するのがソリューションを記述するのと同じくらい難しいことがわかりました。仕様を例示することの素晴らしい点の1つは、特にソフトウェアを書く対象となる非技術者にとって、例を思いつくのが通常ははるかに簡単であるということです。(Timothy Buddは、スタックの動作の多くを事前・事後条件で示すことはできますが、LIFO特性を示す事前・事後条件を書くのは非常に難しいと指摘しました。)

TDDテストの重要な特性は、ダブルチェックを伴うことです。実際、これはXPコミュニティの面白い小さな嘘を浮き彫りにしています。彼らは、一度だけ、一度だけと言うことを非常に強く主張していますが、実際には常に2回言います。1回はコードで、もう1回はテストでです。Kentは、このダブルチェックの原則が非常に重要な原則であり、人間が常に使用しているものであると指摘しました。ダブルチェックの価値は、ダブルチェックのそれぞれの側面に異なる方法を使用することと密接に結びついています。仕様を例示することをプロダクションコードと組み合わせるということは、両方のことが非常に異なる方法で語られるということなので、エラーを見つける能力が高まります。

形式仕様コミュニティは、特にエラーを起こしやすい人間なしに、設計が仕様を満たしていることを検証するのに常に苦労してきました。仕様を例示する場合は、これが簡単です。仕様を例示することは、理論的には価値が低いが、実際には価値が高いという別のケースです。

契約による設計のファンは、テストの観点から仕様を記述した場合、サプライヤーは特定のテスト入力に対してハードコードされた応答を返すだけで仕様を満たすことができると指摘しました。これに対する私の軽率な答えは、これについて心配しているのであれば、テストと契約による設計の問題はあなたの心配事のほんの一部にすぎないということです。しかし、ここには深刻な点があります。テストは常に不完全であるため、常に他のメカニズムによってバックアップする必要があります。ひねくれた考えを持つ私は、これをプラスとして捉えています。仕様を例示することが十分でないことは明らかであるため、すべてが適切に伝達されるようにするためには、さらに多くのことを行う必要があることは明らかです。従来の要件仕様について最も危険なことの1つは、人々がそれを書いたらコミュニケーションが終わったと考えている場合です。

仕様を例示することは、両者が協力し、戦っていない作業関係の文脈でのみ機能します。例は、設計チームに抽象化を促すと同時に、抽象化を地に足のついたものにします。定期的な会話、ドメイン駆動設計のような手法、さらには契約による設計も必要です。契約による設計を完全に（つまり、Eiffelで）使用する機会はなかったものの、インターフェイスを契約的な観点から考えることはよくあります。仕様を例示することは強力なツールであり、おそらく私が最もよく使うツールですが、決して唯一のツールではありません。

(仕様を例示することに関する詳細な考察については、その名前ではないにしても、Brian Marickの著作をご覧ください。彼のサイトのどこかに、おそらく彼の見解をまとめたスーパーページがあるでしょう。もちろん、それを見つけることは、あなたが試している間、そこにあるすべてのものを読むことほど価値はありません)

後からのコメント

私がこれを最初に書いた数年後、Cedric Beustによる投稿があり、アジャイル手法を批判し、ちょっとしたブログ論争を引き起こしました。Jeff LangrとBob Martinによる反論があり、私はこの投稿をフィードで再送信しました。Jeff Langrは後に、JavaのMath.pow関数に対して仕様を例示するテストを使用した素晴らしい例を追加しました。

2011年11月17日に再投稿