テスト駆動開発
テスト駆動開発（テスト駆動開発、英語:、略称TDD）とは、エクストリーム・プログラミングが提唱したソフトウェア開発プロセスにおける応用手法であり、テストプログラムを書いてからその機能を実装するコーディングを行うことから名付けられました。テスト駆動開発は 1990 年代に始まりました。テスト駆動開発の目的は、迅速なフィードバックを得て、プログラムの構築に「主線を示す」アプローチを使用することです。
| ソフトウェア開発 |
|---|
| コアアクション |
| パラダイムとパターン |
|
| 方法論とフレームワーク |
|
| 支持的な行動 |
| 練習する |
|
| 道具 |
| 標準と知識システム |
|
テスト駆動開発とは、まずテストの助けを借りて機能実装の帽子をかぶって機能を迅速に実現し、次にテストの保護の下で機能を削除することでリファクタリングの帽子をかぶるという2つの帽子で考える開発手法です。コードを冗長化し、コードの品質を向上させます。テストは開発プロセス全体を推進します。まず、コードの設計とその機能の実装を推進し、その後、コードの再設計と再構築を推進します。
テスト駆動開発におけるテストの特徴
テスト駆動開発では基本的にコードが完成した後に要件分析や詳細設計を行う範囲であり、これらのテストも単体テストの一部となります。
応用分野
新しいソフトウェアの開発、過去のシステムの保守。
テスト駆動開発関連のディスカッション
肯定的なレビュー
- 可以有效的避免过度设计带来的浪费。但是也有人强调在开发前需要有完整的设计再实施可以有效的避免重构带来的浪费。
- 可以让开发者在开发中拥有更全面的视角。
负面评价
- 开发者可能只完成满足了测试的代码，而忽略了对实际需求的实现。有实践者认为用结对编程的方式可以有效的避免这个问题。
- 会放慢开发实际代码的速度，特别对于要求开发速度的原型开发造成不利。这里需要考虑开发速度需要包含功能和品質两个方面，单纯的代码速度可能不能完全代表开发速度。
- 对于GUI,資料库和Web应用而言。构造单元测试比较困难，如果强行构造单元测试，反而给维护带来额外的工作量。有开发者认为这个是由于设计方法，而不是开发方法造成的困难。
- 使得开发更为关注用例和测试案例，而不是设计本身。目前，对于这个观点有较多的争议。
- 测试驱动开发会导致单元测试的覆盖度不够，比如可能缺乏边界测试。在实际的操作中，和非测试驱动开发一样，当代码完成以后还是需要补充单元测试，提高测试的覆盖度。
参见
外部連結
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.