2010年7月17日 (土) 09:26時点における版編集しまあじ (会話 \| 投稿記録) 94,774 回編集 C:CITE分類、日付は履歴から ← 古い編集		2010年8月14日 (土) 07:19時点における版編集取り消し Yuichirou (会話 \| 投稿記録) 1,379 回編集編集の要約なし新しい編集 →
1行目: {{出典の明記\|date=2008年12月}} '''テスト駆動開発''' (てすとくどうかいはつ、test-driven development; TDD) とは、[[プログラム (コンピュータ)\|プログラム]]開発手法の一種で、プログラム~~本体よりも先~~に必要な各機能について、最初に[[ソフトウェアテストケー\|テスト]]を書~~くスタイルである。~~き（こ~~のスタイル~~れを'''テストファースト'''と言う）、そのテストが動作する必要最低限な実装をとりあえず行った後、コードを洗練させる、ともいう短い工程を繰り返すスタイルである。多くの[[アジャイルソフトウェア開発]]手法、例えば[[エクストリーム・プログラミング]]において強く推奨されている。近年は[[ビヘイビア駆動開発]]へと発展を遂げている。 == 開発サイクル == 6行目: 失敗するテストを書くできる限り早く、テストがパスするような最小限のコード本体を書くコードの重複を除去する（[[リファクタリング~~をする~~ (プログラミング)\|リファクタリング]]）テストの実行環境ツールである[[xUnit]]では、テストの失敗を赤いバー、成功を緑のバーで通知するため、上記のサイクルは Red/Green/Refactor と称される。より実践的には、to-doリストの利用を組み合わせた以下の手順で開発を行う。まず、現時点で分かっている範囲でテストの必要性がある項目をリストとして列挙する。このリストは適時、テストの必要性がわかった時点でその項目を追加していく。このリストから１1つ選ぶ。これは、実装できそうなものでしかしトリビアルでないものを選ぶ（テスト自体の記述が容易でも、Fake It（後述）でしかコード本体を記述できなさそうなものは後回しにする）。実装できそうなものが無い場合は、列挙した項目の粒度が大きすぎることを意味する。その場合、それを実装するための前提にできるような、より小さい粒度の項目を作りリストに加える。選択した項目についてテストを記述する。このテストは、現在の実装を用いると失敗するようなものを選ぶ。コンパイルに必要な最小限のコード（例えば、まだ存在しないクラス・メソッドを利用するテストを書いたなら、そのクラス・メソッドの宣言）の追加後、実際にテストを実行し失敗することを確認する。期せずしてテストがパスした場合は、意図しないことが起こっていることに注意する。テストが失敗するまでは、コード本体は触らない。できる限り早くテストの失敗を解消するようにコード本体を記述する。この段階では、テストをパスさせるためにどんなことをしても良い（定数を返す、コピー＆&ペースト、コードの重複等）。具体的には３3つの方法が挙げられる。実装が自明な場合~~（～１~~（1分程度で書ける場合）はそれを記述する（Obvious Implementation）。テストに要求される値そのものをハードコーディングする（Fake ~~It)~~It；仮実装）。 *Fake Itの後に次のリファクタリングの段階へ進めないような漠然としている場合は、さらに別のデータを用いたテストを追加し、その２2つのテストの共通点を見出して助けとする~~（Triangulate）~~（Triangulate；三角測量）。テストがパスすることを保持しつつ、コード本体やそれとテストの間の明示的・暗黙的重複を取り除く（リファクタリング）。通常、リファクタリングとはコードの意味を変えずに再構築することを言うが、ここでは、「コードの意味」はテストが通ることを言う。リファクタリングで取り除く対象となる重複は、形式的なものだけではなく意味的なものも含む。例えば、Fake Itでハードコーディングしたものはおおよそ、実際にはどこからか得られるはずのパラメータの値を、それとは別に値を用いて算出したものであり、これを重複と見なす。重複を取り除くことでロジックが抽出される。リストから実装した項目を削除する。作業中にテストの必要性が判明した他の項目に、実質的に振り変わるかもしれない。 25行目: テスト駆動開発で用いられるテストは、品質のためのテストではない。コード本体とは独立にあらゆるケースを網羅するような、テスト自体で価値を持つようなものは目指していない。コード本体を合わせて検討することで、開発者が、その正しさに確信を得るものである。開発者の確信に少しも寄与しないテスト（かつ、ドキュメントとしてテストの読者に何かを伝えるために書かれたものではないもの）は、むしろ積極的に削除を検討する。テスト駆動開発を実施するには、テストを自動的に実行できる環境が必要である。そのような環境としては、[[JUnit]]や[[NUnit]]といったもの（総称して[[xUnit]]とされる）が挙げられる。なお、このテスト実行環境は、コンセプトが簡単なわりに非常に強力なツールであることから、新しい言語の習得を兼ねてそれ自体をテスト駆動開発で自作するのもよい。ただし、そのテストツールをテストするツールは無いことから、しばらくは慎重な人の判断でもってテストの代わりとすることになる。なお、このテスト実行環境は、コンセプトが簡単なわりに非常に強力なツールであることから、新しい言語の習得を兼ねてそれ自体をテスト駆動開発で自作するのもよい。ただし、そのテストツールをテストするツールは無いことから、しばらくは慎重な人の判断でもってテストの代わりとすることになる。 ==利点== 39 ⟶ 38行目: ==適用の注意== テスト駆動開発に適合させるのが難しいものに、以下のものが挙げられる。 45 ⟶ 43行目: 並列処理前者は、盲目的にその良し悪し判断できない（人の判断が必要である）こと、後者は、再現性に問題があるためやはり盲目的に良し悪しを判断できないためである。不具合がないことは前提であるため、その点に関してはテスト駆動の効果はある。 ~~しを判断できないためである。不具合がないことは前提であるため、その点に関してはテスト駆動の効果はある。~~ 以下のものもテスト駆動開発が難しいとの指摘がある (Darach's Challenge) 56 ⟶ 53行目: 既に構築してあるコードに対して、テスト駆動開発を導入するのも難しい。それらのコードは得てしてテストがしやすいようには作られていないため、先にリファクタリングをする必要があるが、リファクタリングを行うにはその動作の保証をするためのテストが必要である（デッドロック）。やってはいけないことは、片っ端からテストを書いたり、リファクタリングを行うことである。変更する範囲を制限することを決心し、何らかのフィードバックを得ることを前提として（例えば、ペアリングで注意深く作業を行う、アプリケーションレベルのテストなど）コードを変更していくことが必要である。 == 参考文献 ==▼ * {{Cite book\|last=Beck\|first=Kent\|year=2002\|title=Test-Driven Development: By Example\|publisher=Addison-Wesley Professional\|pages=240\|isbn=0321146530}} ** {{Cite book\|和書\|author=ケント・ベック\|authorlink=ケント・ベック\|others=長瀬嘉秀監訳、（株）テクノロジックアート訳\|year=2003\|title=テスト駆動開発入門\|publisher=ピアソン・エデュケーション\|isbn=4894717115\|ref=tdd}} ==関連項目== 71 ⟶ 72行目: ==外部リンク== [http://www.atmarkit.co.jp/fdotnet/special/tdd/tdd_01.html 特集「テスト駆動開発」はプログラマのストレスを軽減するか？（@IT）]: [[テストファースト]]とテスト駆動開発との違い、テスト駆動開発の具体的な手法について書かれている。 ▲== 参考文献 == Kent Beck, Test-Driven Development: By Example, The Addison-Wesley Signature Series, 2003 {{DEFAULTSORT:てすとくとうかいはつ}}

「テスト駆動開発」の版間の差分