1
00:00:00,096 --> 00:00:04,652
ここでは５章のテスト概要について紹介します。

2
00:00:04,652 --> 00:00:09,188
これはブライアン・カニンガム、ベル研究所の偉人であり、

3
00:00:09,188 --> 00:00:13,956
ほとんどの人が持っていると思いますが、C言語のカニンガム・リッチー本の著者です。

4
00:00:13,956 --> 00:00:17,680
それを２・３回読むとわかることは、

5
00:00:17,680 --> 00:00:19,605
デバックは最初にコードを書いた二倍の苦労をするということ。

6
00:00:19,605 --> 00:00:23,798
二倍の苦労です。ですから、もし最初にとても最高にうまいコードを書いたとしたら、

7
00:00:23,798 --> 00:00:27,541
デバックする必要はないでしょう。二倍の苦労ですから。

8
00:00:27,541 --> 00:00:38,320
そしてこの人、ダイクストラです。吹き出しの空欄に入れてみてください

9
00:00:38,320 --> 00:00:41,298
テストは、エラーが「ない」ことを示すことはできない、エラーが「ある」ことだけを示すことができる。

10
00:00:41,298 --> 00:00:44,109
それは長い間いわれていることで、覚えておくべきでしょう。

11
00:00:44,109 --> 00:00:51,999
これは一年半前に出た論文です。「Why are things expensive」と言っています。

12
00:00:51,999 --> 00:00:57,119
この研究では、設計時には本質的なバグはなく、

13
00:00:57,119 --> 00:01:01,704
質の悪いテストのやり方が問題だといっています。質の悪いテストプロセスは、

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

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

16
00:01:17,318 --> 00:01:20,890
テスト自動化システムを持っていて、１０パーセントは全てのテストを手動で行っているとのことです。

17
00:01:20,890 --> 00:01:23,880
自分でテストを書いて、自分で出力を確認して、自分でテストを書いて、自分で出力を確認する。

18
00:01:23,880 --> 00:01:31,153
「自分は間違いをしていないか。うん、大丈夫だ！」と。そんなことが今だ通用しているとは信じがたい。ここでは真実ではないとしたい。

19
00:01:31,153 --> 00:01:36,062
アジャイル以前では、独立した品質保証チームがあり、

20
00:01:36,062 --> 00:01:41,882
開発者は全てのフェーズを受け持ちます、開発者は別々にグループ化されます。何らかの形で、

21
00:01:41,882 --> 00:01:45,321
品質保証チームはコードに品質を盛り込もうとします、

22
00:01:45,321 --> 00:01:51,765
またはコードが品質を保っていることを確認します。アジャイルでは、すべてを自分たちでやることが重要です。

23
00:01:51,765 --> 00:01:54,507
継続的にテストします、毎週新しいコードを出します。

24
00:01:54,507 --> 00:01:59,040
他人ではなく、自分で自分のコードをテストする責任があります。

25
00:01:59,040 --> 00:02:03,911
そしてツールは高度に自動化されています。以前にされていたものとは違います。

26
00:02:03,911 --> 00:02:09,040
アジャイルマニフェストの議論では、

27
00:02:09,040 --> 00:02:19,928
良いプロセスによって良い品質を得ることができる、これは品質を保証に特化したグループを持つことよりも、といっています。

28
00:02:19,928 --> 00:02:22,516
もしそうしなかったら彼らはきっと怒ることでしょう。

29
00:02:22,516 --> 00:02:27,875
最初に言ったように、BDDとTDDは、「ビヘイビア駆動設計」のフレーズが人によっては想起され、

30
00:02:27,875 --> 00:02:32,624
テスト駆動開発とごっちゃになっているかもしれません。

31
00:02:32,624 --> 00:02:35,682
BDDでは、受け入れテスト、統合テスト、そして、ビヘイビア（振る舞い）を捉えようとします。

32
00:02:35,682 --> 00:02:41,359
TDDでは、ステップの定義し、実際に単体テストや機能テストを書きます。

33
00:02:41,359 --> 00:02:46,133
コードを書く前に、常に最新のテストがあります。

34
00:02:46,133 --> 00:02:52,034
というのは、コードを書き始める前にテストコードを書くからです。

35
00:02:52,034 --> 00:02:59,516
ここではBDDとTDDがどのようにいっしょに動くかを説明します。Cucmberでは、フィーチャを記述し、ストーリーを書いて、

36
00:02:59,516 --> 00:03:03,558
それらが失敗します。CucumberはRSpecテストを呼び出しますが、

37
00:03:03,558 --> 00:03:07,688
失敗します。それから失敗したメソッドの実装をします。

38
00:03:07,688 --> 00:03:12,699
そしてRSpecのテストが通るまで、このイテレーションを繰り返します。

39
00:03:12,699 --> 00:03:20,143
いったん正しく実装されたら、Cucumberの緑色のステップなるでしょう。

40
00:03:20,143 --> 99:59:59,999
そして戻って、開発を続けていきます。