Code craft

第8章テスト

経験上自分がテストで難しいと思っているところ

• AP,DBなど外部システムとの連携
• Webアプリ（GUI）
• コードの設計が悪い（構造化やクラス化されていない）
• 既存コードの拡張なので自分でコーディングしていない（ほぼコピペで出来ている）

以下本文よりメモ

「テストのたった1つの最重要なルールは、それをすること」（プログラミング作法）

自分が書いたソースコードをテストする責任はプログラマー自身
QAの仕事は根本的なエラーを発見することでだらしないプログラマの後始末をすることではない
（ここらへんはこの前のWeb+DBのTechMeetingでの岡島さんの講演の話に通じると思う）

テストに何が必要か

• テストコード
• コードレビュー

いつテストをするのか

• コードを書きながらテスト
  理由:実施するのが遅いほどコストがかかる

コードを書く前か、コードを書いたらすぐにテストを書く！！
→これによりテストを考慮した設計になる。（ならざるを得ない）

バグを発見したらその度にテストを追加する！

ある特定のコードがうまく動くかどうかをテストするには

• 有効なすべての入力に対して正しい出力が生成される
• 無効なすべての入力に対して適切な障害動作が生成される

でもこれって難しい。
有効な入力も無効な入力もものすごい数がある。
コード内部に分岐や条件があるとさらに複雑になる。
他にも

• 依存関係
• 外部入力（共有グローバル変数やDB,APIなど）
• 外部刺激

などにより大変になってくる

テストのタイミング

段階	ブラック/ホワイト	一般的なアプローチ	テスト実行者
要件収集	ブラック	ブラックボックステストの考案	開発者,QA
コード設計	ブラック	ブラックボックステストの考案	開発者,QA
コーディング	ブラック,ホワイト	単体,コンポーネント,回帰	開発者
コード統合	ブラック,ホワイト	統合,コンポーネント,回帰	開発者
α状態	ブラック,ホワイト	回帰,負荷,ストレス,ソーク,ユーザビリティ	開発者,QA
β状態	ブラック,ホワイト	回帰,負荷,ストレス,ソーク,ユーザビリティ	QA
リリース候補	ブラック,ホワイト	回帰,負荷,ストレス,ソーク	QA
リリース	ブラック,ホワイト	もはや遅すぎる・・・	ユーザ

単体テストケースの選択

むやみやたらではなく欠陥を暴く可能性の高いテストを選ぶ必要がある
ブラックボックステストを行うには以下のようなテストケースが有効

正しい入力1	中位の値をいくつか
正しい入力2	下限の値をいくつか
正しい入力3	上限の値をいくつか
間違った入力1	非常に大きい数値,非常に小さい数値,負の数値
間違った入力2	長すぎる入力,短すぎる入力,空文字
間違った入力3	内部的に矛盾するデータ値
境界値	境界値,すぐ上の値,すぐ下の値
ランダムなデータ
ゼロ	0,nullポインタ