山本＠エプソンコーワです。
ご指摘ありがとうございます。
> > たことであった。私達がテストを入力ファイルから出力ファイルに実行した後に
> さ
> > え、
> > 私達はそのファイルを使った下流のプログラムの違いを後で発見した。私達がア
> ウト
> > プ
>
> 下流のプログラム【で】違いを発見した。
>
> differencesは、当初の出力ファイルのデータと正しい出力ファイ
> ルのデータの違いのことなんだろうと勝手に解釈しました。
>
> > ットであるはずのものを誤解した時には、これは典型的に起こった;ファイルは
> 私達
> > が意
> > 図したものを持ち、テストによりその値がチェックされたけれども、Legacy プ
> ログ
> > ラム
> > は何か他のもの要求した。インプットからアウトプットへの機能テスト期間をで
> きる
> > 限
> > り長くしなさい: 欠陥は、あなたが止まる所どこにでも出現する。
>
> 私は、こんなことを言っているのかな、と思いました。
>
> ファイルＡ → プログラムＸ → ファイルＢ → プログラムＹ →
> ファイルＣ
> とあったとき、Ａ−Ｘ−Ｂのテストではうまく動作したが、その結
> 果であるＢを使ったＢ−Ｙ−Ｃでバグが検出されることがある。
> これはＹで必要とするデータをＸで生成していないことが原因であ
> る。このバグは、プログラムＸだけやプログラムＹだけに注目して
> テストしても検出されない。
> このようなバグを検出するために、できるだけ長い系列（上記の場
> 合、入力Ａ、中間ファイルＢ、出力Ｃ）でテストをしなさい。
>
なるほど、納得しました。というか、やっと腑に落ちた感じです。
> 訳を投稿するときには、以下の２行を添付することが約束事になっ
> ています。
> 今後は添付して投稿しましょう。
>
これはすっかり忘れてました、すみません。
以上ふまえて、内容を見直したものを再度投稿します。
私の訳が拙いせいもありますが、訳文だけでは分かりづらいですね。
佃さんのコメントも併せて読んで頂けるとよいかと思います。
この後、'27. Unit Testing'を訳したいと思います。
-------------------------------------------------------------
C3プロジェクトには、最初から最後までシステムをテストし、入力ファイルか
ら出力ファイルを作成する、文字どおり数百個の機能テストがある。テストケ
ースはユーザーにより定義され、テストを作成することを仕事とする別のチー
ムにより開発された。
機能テストはそれら自身の特別なGUIを持っており、テストのステップ、実行時
間、テストが成功したかどうかを表示する。スコアを表示する。
機能テストはプロジェクト中は100%を得点する必要がなかった:機能を付加する
ことでそれらのスコアは上昇する。それらはリリース前に100%のスコアを取る
必要があり、そしてテスト中のどのような現実の変化も注目に値する。
私達はコードをGemStone等に移動させる前に実行する機能テストの短い一式を
持っており、開発中すべての機能テストが毎日実行され、スコアはチームに報
告された。テストチームは、動作していたテストが失敗したときの認識におい
て積極的であり、何かが悪くなったように見えるとすぐに開発者に知らせる。
私達が機能テストによって犯した誤りの1つが、テストが十分に機能の全体に及
んでいなかったことであった。私達が入力ファイルから出力ファイルへのテス
トを実行した後にさえ、後から私達はその出力ファイルを使った下流のプログ
ラムで(その出力ファイルの)間違いを発見した。私達が出力されるべきものを
誤解した時には、これは典型的に起こった; ファイルは私達が意図したものを
持ち、テストによりその値がチェックされたけれども、下流の Legacy プログ
ラムは何か他の(ファイルにない)ものを要求した。入力から出力への機能テス
トのスパンをできる限り長くとりなさい: 欠陥は、あなたが止まる所どこにで
も現われるだろう。
> ---
> オリジナル http://www.xprogramming.com/
> Copyright (c) 1999, REJeffries et al. (ronjeffries@....org)
>
> --
>