0:00:00.096,0:00:04.652
ここでは５章のテスト概要について紹介します。

0:00:04.652,0:00:09.188
これはブライアン・カニンガム、ベル研究所の偉人であり、

0:00:09.188,0:00:13.956
ほとんどの人が持っていると思いますが、C言語のカニンガム・リッチー本の著者です。

0:00:13.956,0:00:17.680
それを２・３回読むとわかることは、

0:00:17.680,0:00:19.605
デバックは最初にコードを書いた二倍の苦労をするということ。

0:00:19.605,0:00:23.798
二倍の苦労です。ですから、もし最初にとても最高にうまいコードを書いたとしたら、

0:00:23.798,0:00:27.541
デバックする必要はないでしょう。二倍の苦労ですから。

0:00:27.541,0:00:38.320
そしてこの人、ダイクストラです。吹き出しの空欄に入れてみてください

0:00:38.320,0:00:41.298
テストは、エラーが「ない」ことを示すことはできない、エラーが「ある」ことだけを示すことができる。

0:00:41.298,0:00:44.109
それは長い間いわれていることで、覚えておくべきでしょう。

0:00:44.109,0:00:51.999
これは一年半前に出た論文です。「Why are things expensive」と言っています。

0:00:51.999,0:00:57.119
この研究では、設計時には本質的なバグはなく、

0:00:57.119,0:01:01.704
質の悪いテストのやり方が問題だといっています。質の悪いテストプロセスは、

0:01:01.704,0:01:10.452
コードの中に多くのバグを存在させる原因となると。さらにここで、完全なテスト自動化環境はほとんどないと言っています。

0:01:10.452,0:01:17.318
これは一年半前ですが、今もってテスト自動化環境はほとんどないでしょう。ソフトウェア開発組織のちょうど１２パーセントは

0:01:17.318,0:01:20.890
テスト自動化システムを持っていて、１０パーセントは全てのテストを手動で行っているとのことです。

0:01:20.890,0:01:23.880
自分でテストを書いて、自分で出力を確認して、自分でテストを書いて、自分で出力を確認する。

0:01:23.880,0:01:31.153
「自分は間違いをしていないか。うん、大丈夫だ！」と。そんなことが今だ通用しているとは信じがたい。ここでは真実ではないとしたい。

0:01:31.153,0:01:36.062
アジャイル以前では、独立した品質保証チームがあり、

0:01:36.062,0:01:41.882
開発者は全てのフェーズを受け持ちます、開発者は別々にグループ化されます。何らかの形で、

0:01:41.882,0:01:45.321
品質保証チームはコードに品質を盛り込もうとします、

0:01:45.321,0:01:51.765
またはコードが品質を保っていることを確認します。アジャイルでは、すべてを自分たちでやることが重要です。

0:01:51.765,0:01:54.507
継続的にテストします、毎週新しいコードを出します。

0:01:54.507,0:01:59.040
他人ではなく、自分で自分のコードをテストする責任があります。

0:01:59.040,0:02:03.911
そしてツールは高度に自動化されています。以前にされていたものとは違います。

0:02:03.911,0:02:09.040
アジャイルマニフェストの議論では、

0:02:09.040,0:02:19.928
良いプロセスによって良い品質を得ることができる、これは品質を保証に特化したグループを持つことよりも、といっています。

0:02:19.928,0:02:22.516
もしそうしなかったら彼らはきっと怒ることでしょう。

0:02:22.516,0:02:27.875
最初に言ったように、BDDとTDDは、「ビヘイビア駆動設計」のフレーズが人によっては想起され、

0:02:27.875,0:02:32.624
テスト駆動開発とごっちゃになっているかもしれません。

0:02:32.624,0:02:35.682
BDDでは、受け入れテスト、統合テスト、そして、ビヘイビア（振る舞い）を捉えようとします。

0:02:35.682,0:02:41.359
TDDでは、ステップの定義し、実際に単体テストや機能テストを書きます。

0:02:41.359,0:02:46.133
コードを書く前に、常に最新のテストがあります。

0:02:46.133,0:02:52.034
というのは、コードを書き始める前にテストコードを書くからです。

0:02:52.034,0:02:59.516
ここではBDDとTDDがどのようにいっしょに動くかを説明します。Cucmberでは、フィーチャを記述し、ストーリーを書いて、

0:02:59.516,0:03:03.558
それらが失敗します。CucumberはRSpecテストを呼び出しますが、

0:03:03.558,0:03:07.688
失敗します。それから失敗したメソッドの実装をします。

0:03:07.688,0:03:12.699
そしてRSpecのテストが通るまで、このイテレーションを繰り返します。

0:03:12.699,0:03:20.143
いったん正しく実装されたら、Cucumberの緑色のステップなるでしょう。

0:03:20.143,9:59:59.000
そして戻って、開発を続けていきます。