ユニットテストは、シティグループがこの高価な間違いを避けるのに役立ちましたか？

私はこのスナフについて読みました：正当な取引が15年間テストデータと間違えられた後、Citigroupのプログラミングバグには700万ドルの費用がかかります。

システムが1990年代半ばに導入されたとき、プログラムコードは、089から100までの3桁のブランチコードが与えられたトランザクションを除外し、それらのプレフィックスをテスト目的で使用しました。

しかし1998年に、同社は事業を拡大するにつれて英数字のブランチコードの使用を開始しました。その中にはコード10B、10Cなどがあり、システムは除外範囲内にあると見なしたため、SECに送信されたレポートからそれらのトランザクションは削除されました。

（これは、非明示的なデータインジケーターを使用することは...最適ではないことを示していると思いBranch.IsLiveます。セマンティックに明示的なプロパティを設定して使用する方がはるかに良いでしょう。）

それはさておき、私の最初の反応は「ユニットテストはここで助けになるだろう」でした...しかし、彼らはどうでしょうか？

最近読んだのは、ほとんどのユニットテストがなぜ無駄なのかということでした。そのため、私の質問は次のとおりです。英数字ブランチコードの導入で失敗したユニットテストはどのようなものでしょうか。

あなたは本当に「単体テストはここで助けたでしょうか？」と尋ねていますか、それとも「何らかの種類のテストがここで助けたでしょうか？」

助けになるテストの最も明白な形式は、コード自体の前提条件アサーションです。ブランチ識別子は数字のみで構成されます（これは、コードを書く際にコーダーが依存する仮定であると仮定します）。

これは、ある種の統合テストで失敗する可能性があり、新しい英数字のブランチIDが導入されるとすぐに、アサーションが爆発します。しかし、それは単体テストではありません。

または、SECレポートを生成する手順の統合テストがあります。このテストは、すべての実際のブランチ識別子がそのトランザクションを報告することを保証します（したがって、実際の入力、使用中のすべてのブランチ識別子のリストが必要です）。したがって、それは単体テストでもありません。

関連するインターフェイスの定義やドキュメントは表示されませんが、ユニットが故障していないため、ユニットテストでエラーを検出できなかった可能性があります。ユニットがブランチ識別子が数字のみで構成されていると想定することが許可されており、開発者がコードがそうでない場合に何をすべきかを決定したことがない場合、彼らはすべきではありません数字以外の識別子の場合に特定の動作を強制する単体テストを作成します。これは、英数字ブランチ識別子を正しく処理したユニットの仮想の有効な実装をテストが拒否するためです。将来の実装と拡張。または、40年前に書かれた1つの文書は、10Bは実際には089から100の間にあるため、テスト識別子であると暗黙的に定義されています（生のEBCDICの辞書編集範囲を介して）。 15年前、誰かがそれを実際の識別子として使用することを決めたため、「欠陥」は元の定義を正しく実装するユニットにはありません。10Bがテスト識別子として定義されているため、ブランチに割り当てるべきではないことに気づかなかったプロセスにあります。089-100をテスト範囲として定義し、識別子10 $または1.0を導入すると、ASCIIでも同じことが起こります。EBCDICでは、文字の後に数字が来ることがあります。

一つのユニットテスト（またはおそらく機能テスト）が考えられます1日を節約できたかもしれませんが、新しいブランチ識別子を生成または検証するユニットのテストです。このテストは、識別子に数字のみが含まれている必要があることを表明し、ブランチ識別子のユーザーが同じ数字を想定できるようにするために記述されます。または、実際のブランチ識別子をインポートしても、テスト識別子は表示されず、すべてのテスト識別子を拒否するようにユニットテストできるユニットがあるかもしれません（識別子が3文字のみの場合、すべてを列挙し、動作を比較できます）テストフィルターのバリデーターが一致することを確認します。これにより、スポットテストに対する通常の異議が処理されます。次に、誰かがルールを変更したとき、ユニットテストは新しく必要な動作と矛盾するため失敗します。

テストは正当な理由で行われたため、ビジネス要件の変更により削除する必要があるポイントは、誰かが仕事を与えられる機会になります。「コードの中で、私たちがしたい動作に依存するすべての場所を見つける変化する"。もちろん、これは難しく、したがって信頼性が低いため、1日の節約を保証するものではありません。あなたがの性質を想定しているユニットのテストであなたの仮定をキャプチャした場合でも、あなたは自分にチャンスを与えてくれたので、努力がされていない完全に無駄になります。

もちろん、ユニットが「面白い形の」入力で最初に定義されていなかった場合、テストするものは何もないことに同意します。面倒な名前空間の分割は、あなたの面白い定義を実装することに困難がなく、誰もがあなたの面白い定義を理解し、尊重することを確認することにあるため、適切にテストするのが難しい場合があります。これは、1つのコード単位のローカルプロパティではありません。さらに、一部のデータ型を「数字の文字列」から「英数字の文字列」に変更することは、ASCIIベースのプログラムでUnicodeを処理することに似ています。コードが元の定義に強く結合している場合、データ型は、プログラムが行うことの基本であり、多くの場合、強く結合されます。

それは主に無駄な努力だと思うのは少し不安です

ユニットテストが時々失敗する場合（リファクタリング中など）、そうすることで有用な情報（たとえば、変更が間違っている）が提供されれば、労力は無駄になりませんでした。彼らがしないことは、システムが動作するかどうかをテストすることです。したがって、機能テストや統合テストを行う代わりに単体テストを作成している場合、時間を最適に使用していない可能性があります。

単体テストでは、ブランチコード10Bおよび10Cが「テストブランチ」として誤って分類されていることを検出できましたが、そのブランチ分類のテストがそのエラーを検出するのに十分な広さだったとは思われません。

一方、生成されたレポートのスポットチェックにより、バグが存在するようになった15年よりもずっと早く、分岐10Bおよび10Cが一貫してレポートから欠落していることが明らかになった可能性があります。

最後に、これは、1つのデータベースでテストデータと実際の運用データを混在させるのが悪い考えである理由を示しています。テストデータを含む別のデータベースを使用していた場合、公式レポートから除外する必要はなく、除外することは不可能でした。

ソフトウェアは特定のビジネスルールを処理する必要がありました。単体テストがある場合、単体テストは、ソフトウェアがビジネスルールを正しく処理したことを確認していました。

ビジネスルールが変更されました。

どうやら、ビジネスルールが変更されたことに誰も気づかず、新しいビジネスルールを適用するためにソフトウェアを変更した人はいませんでした。単体テストがあった場合、それらの単体テストを変更する必要がありますが、ビジネスルールが変更されたことに誰も気付かなかったため、誰もそれを実行しませんでした。

そのため、ユニットテストではそれを把握できませんでした。

例外は、単体テストとソフトウェアが独立したチームによって作成され、単体テストを行うチームが新しいビジネスルールを適用するためにテストを変更した場合です。その場合、単体テストは失敗し、ソフトウェアの変更が発生することを期待していました。

もちろん、単体テストではなくソフトウェアのみが変更された場合、同じ場合、単体テストも失敗します。単体テストが失敗するたびに、それはソフトウェアが間違っているという意味ではなく、ソフトウェアまたは単体テスト（時には両方）が間違っていることを意味します。

いいえ。これは、単体テストの大きな問題の1つです。これらは、あなたを誤った安心感に陥らせます。

すべてのテストに合格しても、システムが正常に機能しているわけではありません。すべてのテストに合格していることを意味します。それは、あなたが意識してテストを書いたあなたのデザインの部分が、あなたが意図的に思った通りに機能していることを意味します。とにかく、とにかくあなたはそれを正しくした可能性が高いです！しかし、あなたがそれらのテストを書くことを考えたことがないので、あなたがそれらのような、あなたが考えなかったケースをキャッチすることは何もしません。 （もしあれば、それはコードの変更が必要であることを知っていたでしょう、そしてあなたはそれらを変更したでしょう。）

いいえ、必ずしもそうではありません。

元の要件は数値分岐コードを使用することでしたので、さまざまなコードを受け入れ、10Bのようなものを拒否したコンポーネントに対して単体テストが作成されていました。システムは動作しているものとして渡されていたはずです（動作していました）。

次に、要件が変更され、コードが更新されますが、これは不良データ（現在は良好なデータ）を提供するユニットテストコードを変更する必要があることを意味します。

システムを管理する人々はこれが事実であることを知っており、新しいコードを処理するために単体テストを変更するでしょう...しかし、彼らがそれが起こっていることを知っていたなら、彼らはこれらを処理するコードを変更することも知っていたでしょうとにかく..そして彼らはそれをしませんでした。元々コード10Bを拒否した単体テストは、そのテストを更新することを知らなかった場合、実行時に「ここですべては問題ありません」と喜んで言うでしょう。

単体テストは、元の開発には適していますが、システムテストには適していません。特に、要件が長く忘れられてから15年はかかりません。

この種の状況で必要なのは、エンドツーエンドの統合テストです。動作するはずのデータを渡し、動作するかどうかを確認できる場所。誰かが、新しい入力データではレポートが作成されないことに気づき、さらに調査します。

型テスト（ランダムに生成された有効なデータを使用して不変条件をテストするプロセス。HaskellテストライブラリQuickCheckや、他の言語でそれに触発されたさまざまなポート/代替が例として挙げられます） 。

これは、ブランチコードの有効性のルールが更新されたときに、それらが正しく機能することを確認するために特定の範囲をテストすることを誰も考えなかったためです。

しかし、型式試験が使用されていた場合、誰かが必要があり、元のシステムが実施された時の特性の組を書かれている、一つは試験分岐のための特定のコードがない他のコードいることを確認するテストデータと一つとして扱われたことを確認します分岐コードのデータ型定義が更新されたとき（数字から数値への分岐コードの変更のいずれかが機能することをテストするために必要だった）、このテストは値のテストを開始していました新しい範囲であり、ほとんどの場合、障害を特定しているでしょう。

もちろん、QuickCheckは1999年に最初に開発されたため、この問題をキャッチするには遅すぎました。

ユニットテストがこの問題に影響を与えることは本当に疑わしい。新しい分岐コードをサポートするために機能が変更されたため、トンネルビジョンの状況の1つのように聞こえますが、これはシステムのすべての領域で実行されませんでした。

ユニットテストを使用してクラスを設計します。単体テストの再実行は、設計が変更された場合にのみ必要です。特定のユニットが変更されない場合、未変更のユニットテストは以前と同じ結果を返します。単体テストでは、他のユニットへの変更の影響を示すことはできません（そうする場合は、単体テストを作成していません）。

この問題は、次の方法でのみ合理的に検出できます。

• 統合テスト-ただし、システム内の複数のユニットにフィードする新しいコード形式を具体的に追加する必要があります（つまり、元のテストに有効なブランチが含まれている場合にのみ問題が表示されます）
• エンドツーエンドのテスト-ビジネスは、古いブランチコード形式と新しいブランチコード形式を組み込んだエンドツーエンドテストを実行する必要があります

十分なエンドツーエンドのテストがないことは、より心配です。システム変更のONLYまたはMAINテストとして単体テストに依存することはできません。新たにサポートされたブランチコード形式でレポートを実行する必要があるのは誰かのようです。

ランタイムに組み込まれたアサーションが助けになったかもしれません。例えば：

1. のような関数を作成する bool isTestOnly(string branchCode) { ... }
2. この機能を使用して、除外するレポートを決定します
3. アサーション、ブランチ作成コードでその関数を再利用して、このタイプのブランチコードを使用してブランチが作成されていない（作成できない）ことを確認またはアサートします！
4. このアサーションを実際のランタイムで有効にします（「デバッグ専用の開発者バージョンのコードを除き、最適化されていない」）！

こちらもご覧ください：

• 「デバッグ」ビルドと「リリース」ビルドを分離しますか？（つまり、実行時にアサーションを有効にします）
• 1つの内部実装をテストする必要がありますか、それとも公開動作のみをテストする必要がありますか （つまり、システムテストは単体テストよりも有用で、カバレッジが優れている可能性があります）

これの要点は、Fail Fastです。

コードがなく、コードに応じてテスト分岐プレフィックスであるかどうかを示すプレフィックスの例もありません。これだけです：

• 089-100 =>テストブランチ
• 10B、10C =>テストブランチ
• <088 =>おそらく実際のブランチ
• > 100 =>おそらく実際のブランチ

コードが数字と文字列を許可しているという事実は、少し奇妙です。もちろん、10Bと10Cは16進数と見なすことができますが、プレフィックスがすべて16進数として扱われる場合、10Bと10Cはテスト範囲外になり、実際の分岐として扱われます。

これは、プレフィックスが文字列として保存されているが、場合によっては数字として扱われることを意味します。以下に、この動作を再現する最も単純なコードを示します（説明のためにC＃を使用）。

bool IsTest(string strPrefix) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix))
        return iPrefix >= 89 && iPrefix <= 100;
    return true; //here is the problem
}

英語では、文字列が数字で、89〜100の場合、テストです。数値でない場合は、テストです。それ以外の場合は、テストではありません。

コードがこのパターンに従う場合、コードがデプロイされた時点で単体テストでこれを検出することはできませんでした。ユニットテストの例を次に示します。

assert.isFalse(IsTest("088"))
assert.isTrue(IsTest("089"))
assert.isTrue(IsTest("095"))
assert.isTrue(IsTest("100"))
assert.isFalse(IsTest("101"))
assert.isTrue(IsTest("10B")) // <--- business rule change

単体テストでは、「10B」をテストブランチとして扱う必要があることが示されています。上記のユーザー@ gnasher729は、ビジネスルールが変更され、それが上記の最後のアサーションが示すものであると言います。ある時点で、アサートはに切り替わるべきisFalseでしたが、それは起こりませんでした。単体テストは開発時およびビルド時に実行されますが、その後は実行されません。

ここでの教訓は何ですか？ コードには、予期しない入力を受け取ったことを知らせる何らかの方法が必要です。このコードを記述する別の方法は、プレフィックスが数字であることを期待することを強調しています。

// Alternative A
bool TryGetIsTest(string strPrefix, out bool isTest) {
    int iPrefix;
    if(int.TryParse(strPrefix, out iPrefix)) {
        isTest = iPrefix >= 89 && iPrefix <= 100;
        return true;
    }
    isTest = true; //this is just some value that won't be read
    return false;
}

C＃を知らない人の場合、戻り値は、コードが指定された文字列のプレフィックスを解析できたかどうかを示します。戻り値がtrueの場合、呼び出しコードはisTest out変数を使用して、ブランチプレフィックスがテストプレフィックスかどうかを確認できます。戻り値がfalseの場合、呼び出しコードは、指定されたプレフィックスが予期されていないことを報告する必要があり、isTest out変数は無意味であり、無視する必要があります。

例外で大丈夫なら、代わりにこれを行うことができます：

// Alternative B
bool IsTest(string strPrefix) {
    int iPrefix = int.Parse(strPrefix);
    return iPrefix >= 89 && iPrefix <= 100;
}

この代替方法はより簡単です。この場合、呼び出し元のコードは例外をキャッチする必要があります。いずれの場合も、コードは、整数に変換できないstrPrefixを予期していないことを呼び出し元に報告する何らかの方法を備えている必要があります。このようにして、コードは迅速に失敗し、銀行はSECの細かい当惑なしに問題を迅速に見つけることができます。

非常に多くの答えがあり、ダイクストラの引用も1つではありません。

テストでは、バグの存在ではなく存在を示しています。

したがって、それは依存します。コードが適切にテストされていれば、おそらくこのバグは存在しません。

ここでの単体テストでは、そもそも問題が存在しないことを確認できたと思います。

あなたがbool IsTestData(string branchCode)関数を書いたと考えてください。

最初に記述するユニットテストは、nullと空の文字列に対して行う必要があります。次に、文字列の長さが正しくない場合、非整数文字列の場合。

これらのすべてのテストに合格するには、関数にパラメーターチェックを追加する必要があります。

10Aの可能性を考えずに「良い」データ001-> 999のみをテストする場合でも、パラメータのチェックにより、英数字の使用を開始するときに、例外がスローされるのを避けるために関数の書き換えが強制されます