-
ここでは５章のテスト概要について紹介します。
-
これはブライアン・カニンガム、ベル研究所の偉人であり、
-
ほとんどの人が持っていると思いますが、C言語のカニンガム・リッチー本の著者です。
-
それを２・３回読むとわかることは、
-
デバックは最初にコードを書いた二倍の苦労をするということ。
-
二倍の苦労です。ですから、もし最初にとても最高にうまいコードを書いたとしたら、
-
デバックする必要はないでしょう。二倍の苦労ですから。
-
そしてこの人、ダイクストラです。吹き出しの空欄に入れてみてください
-
テストは、エラーが「ない」ことを示すことはできない、エラーが「ある」ことだけを示すことができる。
-
それは長い間いわれていることで、覚えておくべきでしょう。
-
これは一年半前に出た論文です。「Why are things expensive」と言っています。
-
この研究では、設計時には本質的なバグはなく、
-
質の悪いテストのやり方が問題だといっています。質の悪いテストプロセスは、
-
コードの中に多くのバグを存在させる原因となると。さらにここで、完全なテスト自動化環境はほとんどないと言っています。
-
これは一年半前ですが、今もってテスト自動化環境はほとんどないでしょう。ソフトウェア開発組織のちょうど１２パーセントは
-
テスト自動化システムを持っていて、１０パーセントは全てのテストを手動で行っているとのことです。
-
自分でテストを書いて、自分で出力を確認して、自分でテストを書いて、自分で出力を確認する。
-
「自分は間違いをしていないか。うん、大丈夫だ！」と。そんなことが今だ通用しているとは信じがたい。ここでは真実ではないとしたい。
-
アジャイル以前では、独立した品質保証チームがあり、
-
開発者は全てのフェーズを受け持ちます、開発者は別々にグループ化されます。何らかの形で、
-
品質保証チームはコードに品質を盛り込もうとします、
-
またはコードが品質を保っていることを確認します。アジャイルでは、すべてを自分たちでやることが重要です。
-
継続的にテストします、毎週新しいコードを出します。
-
他人ではなく、自分で自分のコードをテストする責任があります。
-
そしてツールは高度に自動化されています。以前にされていたものとは違います。
-
アジャイルマニフェストの議論では、
-
良いプロセスによって良い品質を得ることができる、これは品質を保証に特化したグループを持つことよりも、といっています。
-
もしそうしなかったら彼らはきっと怒ることでしょう。
-
最初に言ったように、BDDとTDDは、「ビヘイビア駆動設計」のフレーズが人によっては想起され、
-
テスト駆動開発とごっちゃになっているかもしれません。
-
BDDでは、受け入れテスト、統合テスト、そして、ビヘイビア（振る舞い）を捉えようとします。
-
TDDでは、ステップの定義し、実際に単体テストや機能テストを書きます。
-
コードを書く前に、常に最新のテストがあります。
-
というのは、コードを書き始める前にテストコードを書くからです。
-
ここではBDDとTDDがどのようにいっしょに動くかを説明します。Cucmberでは、フィーチャを記述し、ストーリーを書いて、
-
それらが失敗します。CucumberはRSpecテストを呼び出しますが、
-
失敗します。それから失敗したメソッドの実装をします。
-
そしてRSpecのテストが通るまで、このイテレーションを繰り返します。
-
いったん正しく実装されたら、Cucumberの緑色のステップなるでしょう。
-
そして戻って、開発を続けていきます。
