5
ユニットテストは時期尚早の一般化につながりますか（特にC ++のコンテキストで）？
予備メモ さまざまな種類のテストの違いについては説明しませんが、これらのサイトには既にいくつかの質問があります。 私はそこに何を取るだろうと、それは言う：単位は、「アプリケーションの最小単離ユニットテスト」の意味でのテストこの質問は、実際に由来します 分離の問題 プログラムの最小の分離可能な単位は何ですか。さて、私が見ているように、それは（非常に？）あなたがコーディングしている言語に依存します。 Micheal Feathersは縫い目の概念について語っています：[WEwLC、p31] シームは、その場所で編集せずにプログラムの動作を変更できる場所です。 そして、詳細に立ち入ることなく、私は、ユニットテストのコンテキストで、あなたの「テスト」があなたの「ユニット」とインターフェースできるプログラムの場所であると理解しています。 例 特にC ++の単体テストでは、テスト対象のコードから、特定の問題に対して厳密に要求される継ぎ目を追加する必要があります。 例： 非仮想実装で十分な仮想インターフェースを追加する 分割-generalizing（？）-テストを追加しやすくするための（さらに小さな）クラス 単一の実行可能プロジェクトを、一見「独立した」ライブラリに分割し、テストのためにそれらを独立してコンパイルしやすくするために「ちょうど」。 質問 同じことを願ういくつかのバージョンを試してみましょう。 ユニットテストでアプリケーションのコードを構造化する必要があるのは、ユニットテストに「のみ」有益であるか、実際にはアプリケーション構造に有益ですか。 必要とされるコードの一般化は、それがユニット・テスト可能な何のために有用にすることですが、ユニットテスト？ 単体テストを追加すると、不必要に一般化されますか？ シェイプユニットテストは、コードに「常に」強制することも、問題の領域から見た一般的なコードの良い形ですか。 コードを使用する2番目の場所が必要になるまで/必要になるまで一般化しないと言った経験則を覚えています。単体テストでは、コードを使用する2番目の場所、つまり単体テストが常にあります。それで、この理由は一般化するのに十分ですか？