ホソカワさん、上手です。
ちょっとコメントさせてください。
On Sun, 4 Jun 2000 16:14:06 +0900
Kaoru Hosokawa <khosokawa@....com> wrote:
> ホソカワです。
>
> 18章の解説です。
>
> 単体テストの書き方が少々書かれていますが、もっと説明が欲しかったです。
>
> ----
>
> Chapter 18 Testing Strategy (テスト戦略)
> ========================================
>
> テストの話をしたい人はいません。重要性は認識していますが、開発中にテストまで
> 手がまわらないのが現状です。
>
> プログラマは、自分の書いたコードに自信を持つためにテストを書きます。自信を架
> 空のものから（take confidence out of the ether）具現化して（turn it into an
> artifact）コードに埋めましょう。コードの一部になったテスト（自信）は他の人た
> ちにも自信をあたえることになります。
>
> 顧客も、プログラムの機能に自信を持つためにテストを書きます。顧客の自信はプロ
> グラマの自信と一緒になり、プログラムはますます、自信をつけていきます。
>
> プログラマや顧客にテストを書いてもらうためには、テストを書くプロセスをなるべ
> く簡単にしなくてはなりません。テストはツールであり、大事なのはシステムの動き
> であって、テストそのものではありません。テストなしで開発できるのであれば、真っ
> 先にテストをすてています。
>
> XPのテストは独立（孤立）していて、かつ、自動化されていなければなりません。
>
> テストは、他のテストと互いに干渉しあってはなりません。よって、一つのテストが
> 落ちることでその他の何百というテストを落とすようなことをさけることができます。
> 山積みのエラーを処理していたら、一つのテストが原因だとわかったら、落ち込みま
> すよね（it's a big letdown）。これが毎日続いたら、テストを無視するようになっ
> ていくでしょう。
>
> テストは自動化します。一番テストが重要なときは、プログラマのストレスがピーク
> に達しているときで、判断が鈍っている時です。このような時は、テストが無条件で
> 合格／不合格を判断してくれます。
>
> すべてをテストすることはできません。かといって、何もテストしないことは自殺行
> 為です。では、何をテストするべきでしょう？壊れそうな箇所をテストするべきです。
> どう見てもコードがシンプルなので壊れそうもない箇所はテストしません。
この break はどう解釈すればいいのでしょうか？
１ プログラムがブレークする＝止まる
かと思ったのですが、これでは数が少ないですね。で、
２ 求める動きをしない＝壊れる
と考えたのですが、ホソカワさんの意見と合ってますでしょうか？
>
> テストは賭けです。パスしないはずのテストがパスしたり、パスするはずのテストが
> パスしない時は、チェックが必要です。そこから何かを学べます。学習することによっ
> てより良く開発ができるようになります。
>
> テストを書く事によって、プラスになる（pay off）テストを見極める事ができるよ
> うになって行くでしょう。そうなれば、ペイオフするテストを多く書き、ペイオフし
> ないテストを書かなくなるでしょう。
>
> Who Writes Tests?（だれがテストを書くのでしょう？）
> --------------------------------------------------
>
> プログラマと顧客がテストを書きます。
>
> プログラマは、（単体）テストをメソッドごとに書きます。プログラマは以下の状況
> 下でテストを書きます。
>
> ・メソッドのインターフェースがはっきりしていない場合。
> ・インターフェースは明確でも、実装が複雑そうな場合。
> ・まれな状況でメソッドが動かなくてはならない場合は、その状況が伝わるテストを
> 書く。
> ・後で問題が起きた場合、その問題をチェックするテストを書く。
> ・理解が完璧にされていない箇所をリファクタリングする場合。
>
> プログラマの書いたテストはつねに100%でパスしなくてはならない。もし、テストが
> 落ちた場合、直ちに直さなくてはならない。それは、修正のための作業量がわからな
> いからである。一分でなおるもしれないし、数カ月かかるかもしれない。また、それ
*かも？＊
> は、プログラマがテストを書く事と実行する事を管理できるので、両方を連動される
> ことができるからである。
keep th tests completely in sync. ですので、
＊テスト同士の同期を保つ（同士がぶつからない）＊ では？
>
> 顧客は、（機能）テストをストーリーごとに書きます。機能テストは常に100%でパス
> しなくてもいいのです。機能テストはコードをベースに書かれたものではないので、
> Beck氏はまだ、機能テストとコードを連動する方法を見つけていません。単体テスト
> は100%でなくてはなりませんが、機能テストは、パーセントで評価します。リリース
> に近付くにつれて顧客は重要な問題を見極めて、修正して行かなければなりません。
>
> 顧客は、機能テストを書く事が出来ない場合が多いです。このような時は、テスター
> を起用します。テスターが顧客のテストデータをテストに変換します。また、時間が
> 経つにつれて顧客自身がテストを書けるようなツールを整えて行きます。
>
> 専属のテスターは、プログラマと同じ（経済的）環境下で作業しますので、テスター
> はペイオフするテストを書く事を学習します。ただ、テストを無闇に作成するような
> ことはしません。
>
> Other Tests
> -----------
>
> XPでは、単体テストと機能テストの他に以下のようなテストを採用する事もあります。
>
> ・Parallel test (並列？テスト) - 古いシステムと同じように新しいシステムが機
> 能することを証明するテスト。というより、新システムと旧システムの違いをあらわ
> すテスト。ビジネスの人たちが新システムを導入するタイミングを検討するために使
> う。
> ・Stress test (ストレステスト) - 負荷をかけるテスト
> ・Monkey test (猿？テスト) - ゴミ入力にたえるかどうかのテスト
これはモンキーテストです。パッケージ屋はこれをやります。テスターは、猿が
やるようにキーボードをバンバンたたいて、それでも動作が止まらないことを確
認します。
>
> --
> Kaoru Hosokawa
> khosokawa@....com
>
>