再設計時にテストを効率的に機能させるにはどうすればよいですか？

十分にテストされたコードベースには多くの利点がありますが、システムの特定の側面をテストすると、ある種の変更に耐えるコードベースが得られます。

例は、特定の出力（テキストまたはHTMLなど）のテストです。多くの場合、テストは、特定のテキストブロックを一部の入力パラメーターの出力として期待するため、またはブロック内の特定のセクションを検索するために（単純に？）書き込まれます。

新しい要件を満たすため、またはユーザビリティテストがインターフェイスの変更をもたらしたため、コードの動作を変更するには、テストも変更する必要があります。おそらく、変更されるコードの具体的な単体テストではないテストでさえもです。

• これらのテストを見つけて書き換える作業をどのように管理しますか？「すべてを実行して、フレームワークでそれらを整理する」ことができない場合はどうでしょうか。

• 他にどのようなテスト対象コードが習慣的に脆弱なテストになりますか？

TDDの人々がこの答えを嫌うことは知っていますが、私にとってそれの大部分は、テストする場所を慎重に選択することです。

下位層の単体テストに夢中になりすぎると、単体テストを変更しない限り意味のある変更を加えることができません。インターフェイスが決して公開されておらず、アプリの外部で再利用されることを意図していない場合、これは、さもなければ迅速な変更であったかもしれないものに対する不必要なオーバーヘッドです。

逆に、変更しようとしているものが公開または再利用される場合、変更する必要があるこれらのテストのすべてが、他の場所で何かが壊れている証拠となります。

プロジェクトによっては、単体テストからではなく、受け入れ層からテストを設計することになります。ユニットテストが少なくなり、統合スタイルテストが増えます。

それは、その機能が受け入れ基準を満たすまで、単一の機能とコードを特定できないという意味ではありません。それは単に、場合によっては単体テストで受け入れ基準を測定しないことを意味します。

TCP転送全体を書き換えて、SIPスタックの大規模なオーバーホールを完了しました。（これは、ほとんどのリファクタリングに比べて、かなり大規模な、ほぼリファクタリングでした。）

手短に言えば、TIdSipTransportのサブクラスであるTIdSipTcpTransportがあります。すべてのTIdSipTransportsは、共通のテストスイートを共有しています。TIdSipTcpTransportの内部には、接続/開始メッセージのペア、スレッド化されたTCPクライアント、スレッド化されたTCPサーバーなどを含むマップのような多くのクラスがありました。

私がやったことは次のとおりです。

• 置き換えようとしていたクラスを削除しました。
• それらのクラスのテストスイートを削除しました。
• 左 TIdSipTcpTransportにテストスイートの特定の（そしてすべてのTIdSipTransportsにテストスイートの一般的なのは、まだありました）。
• TIdSipTransport / TIdSipTcpTransportテストを実行し、すべてが失敗したことを確認します。
• 1つのTIdSipTransport / TIdSipTcpTransportテストを除くすべてをコメント化しました。
• クラスを追加する必要がある場合は、コメントなしのテストが合格するのに十分な機能を構築するためのテストを記述します。
• 泡立て、すすぎ、繰り返します。

このように、コメントアウトされたテスト（*）の形で私がまだ何をする必要があるかを知っており、書いた新しいテストのおかげで、新しいコードが期待どおりに機能していることを知っていました。

（*）本当に、コメントアウトする必要はありません。それらを実行しないでください。100のテストに失敗しても、あまり期待できません。また、私の特定のセットアップでは、コンパイルするテストの数が少ないということは、テスト-書き込み-リファクタリングのループが高速になることを意味します。

テストが壊れやすい場合、間違ったものをテストしているため、通常はテストを見つけます。たとえば、HTML出力を考えます。実際のHTML出力を確認すると、テストは脆弱になります。しかし、あなたは実際の出力には興味がなく、それがすべき情報を伝えるかどうかに興味があります。残念ながら、それを行うにはユーザーの脳の内容についてアサーションを行う必要があるため、自動的に行うことはできません。

あなたはできる：

• HTMLを煙テストとして生成し、実際に実行されることを確認します
• テンプレートシステムを使用して、テンプレートプロセッサとテンプレートに送信されたデータをテストできます。実際にテンプレート自体を実際にテストする必要はありません。

SQLでも同じことが起こります。実際のSQLをアサートすると、クラスはあなたをトラブルに陥れようとします。あなたは本当に結果を主張したいです。したがって、ユニットテスト中にSQLITEメモリデータベースを使用して、SQLが想定どおりに実際に動作することを確認します。

まず、新しいAPIを作成します。これは、新しいAPIの動作にしたいことを行います。この新しいAPIの名前が古いAPIと同じである場合は、新しいAPI名に_NEWという名前を追加します。

int DoSomethingInterestingAPI（）;

になる：

int DoSomethingInterestingAPI_NEW（int takes_more_arguments）; int DoSomethingInterestingAPI_OLD（）; int DoSomethingInterestingAPI（）{DoSomethingInterestingAPI_NEW（whatever_default_mimics_the_old_API）; OK-この段階では、DoSomethingInterestingAPI（）という名前を使用して、すべての回帰テストがパスします。

次に、コードを調べて、DoSomethingInterestingAPI（）へのすべての呼び出しをDoSomethingInterestingAPI_NEW（）の適切なバリアントに変更します。これには、新しいAPIを使用するために変更する必要がある回帰テストの部分の更新/書き換えが含まれます。

次に、DoSomethingInterestingAPI_OLD（）を[[deprecated（）]]としてマークします。必要な限り、非推奨のAPIを使用し続けます（それに依存する可能性のあるすべてのコードを安全に更新するまで）。

このアプローチでは、回帰テストの失敗は、単にその回帰テストのバグであるか、コードのバグを特定するだけです。この_NEWおよび_OLDバージョンのAPIを明示的に作成することにより、APIを改訂するこの段階的なプロセスにより、しばらくの間、新しいコードと古いコードの一部を共存させることができます。

実際のこのアプローチの良い（難しい）例がここにあります。関数BitSubstring（）がありました-ここでは、3番目のパラメーターをサブストリング内のビットのCOUNTにするというアプローチを使用していました。C ++の他のAPIやパターンとの一貫性を保つために、関数の引数として開始/終了に切り替えたいと思いました。

https://github.com/SophistSolutions/Stroika/commit/003dd8707405c43e735ca71116c773b108c217c0

新しいAPIを使用して関数BitSubstring_NEWを作成し、それを使用するようにすべてのコードを更新しました（BitSubStringへの呼び出しはありません）。しかし、私はいくつかのリリース（月）で実装を残し、廃止予定としてマークしました。したがって、誰もがBitSubString_NEWに切り替えることができます（その時点で、引数をカウントから開始/終了スタイルに変更します）。

その後-その遷移が完了したら、BitSubString（）を削除してBitSubString_NEW-> BitSubString（）の名前を変更し、BitSubString_NEWという名前を廃止しました。