TDD
Test Driven Development。
テスト駆動開発。 小さな3ステップを回しながら行うソフトウェア開発手法。
1 .テストを作詞し失敗することを確認する(レッド)。
2.1のテストを通す再定義園のコードを実装する(グリーン)
3.リファクタリングを行う。
ステップ2では「テストを通すことだけを考えて作成してよい」という点が精神的負荷を減らし取り掛かりやすいなと感じます。
ステップ3で、外部から見た振る舞えを変えない状態を維持しながらコード内部の設計を良くしていきます。
TDDでのテスト
TDDにおけるテストは、いわゆる品質を図るためのテストではありません。
TDDのテスト
TDDの分類は目的別の分類。
Developer Testing
開発を先に勧めていくためのはずみをつける、開発者のために行うテスト。
自分で書いて自分でテストします。機能要件に対するテスト。
Customer Testing
お客様から見て機能gwどれくらい出来上がっているかを示すこと。
進捗管理に使用します。
QA Testing
品質管理・品質保証の側面からのテスト。
Auality Assuarance(品質保証)。
非機能要件、品質保証のためのテスト。
テスト対象の範囲を基準としたテストの分類
ソフトウェアユニットテスト(単体テスト)
ソフトウェアがソフトウェア詳細設計書通りに正しく動作するかを検証します。
プログラムの部品であるモジュールを単体でテストします。代表的な手法はホワイトボックステスト。開発者が実施。
ソフトウェア結合テスト(結合テスト)
ソフトウェアがソフトウェア方式設計書どおりに正しく動作するかを検証します。
単体テストが完了したモジュールを結合してテストします。
システム適格性確認テスト(システムテスト)
ソフトウェアがソフトウェア要件定義書どおりに正しく動作するかを検証します。
システム結合テスト
システムがシステム方式設計書どおりに正しく動作するかを検証します。
システム適格性確認テスト
システムがシステム要件定義書どおりに正しく動作するかを検証します。
システムテスト
実際に業務手で使うデータや業務上例外として処理されるデータを使って利用者の協力を得て実施。
機能テスト
性能テスト
例外処理テスト
負荷テスト
操作性テスト
進捗管理をテストで行うメリット
テストは二値しかもたないから。
受け入れテストが通っていればその機能は満たされています。
通っていなければ機能を満たしていません。はっきりわかる点が優れています。
身につける有効な方法
■写経
■ペアプロ
■テストファースト
開発対象の機能を考えると課題がたくさん出てきます。
それらを簡単に箇条書きにしてリストにします。
そしてその一つずつに対してその機能を満たすプログラムを作るためのテストコードを書きます。
テストを書くことで望む結果を得るためにどんなプログラムが必要化(ToBe)が得られます。