テストがテストするコードとインラインで書かれていない理由はありますか？

最近、Literate Programmingについて少し読んで、考えさせられました...よく書かれたテスト、特にBDDスタイルの仕様は、散文よりもコードが何をするかを説明するのにより良い仕事をすることができ、大きな利点があります自身の精度を検証します。

テストするコードとインラインで記述されたテストを見たことはありません。これは、言語が同じソースファイルに記述されたときにアプリケーションとテストコードを簡単に分離する傾向がないため（そして誰も簡単にしなかったため）、または人々がテストコードをアプリケーションコードから分離するより原則的な理由があるからですか？

インラインテストで考えられる唯一の利点は、書き込むファイルの数を減らすことです。最近のIDEでは、これはそれほど大したことではありません。

ただし、インラインテストには多くの明らかな欠点があります。

• それは懸念の分離に違反しています。これは議論の余地があるかもしれませんが、私にとって機能のテストは実装とは異なる責任です。
• テスト/実装を区別するために新しい言語機能を導入するか、2つの間の境界があいまいになるリスクがあります。
• ソースファイルが大きいと、作業が難しくなります。読みにくく、理解しにくくなり、ソース管理の競合に対処しなければならなくなる可能性が高くなります。
• いわば「テスター」の帽子をかぶるのが難しくなると思います。実装の詳細を見ると、特定のテストの実装をスキップしたくなるでしょう。

私はいくつかを考えることができます：

• 読みやすさ。「実際の」コードとテストを散在させると、実際のコードを読みにくくなります。

• コードの肥大化。「実際の」コードとテストコードを同じファイル/クラス/より大きなコンパイル済みファイルなどにつながる可能性のあるものに混在させる。これは、レイトバインディングを持つ言語にとって特に重要です。

• 顧客/クライアントにテストコードを見せたくない場合があります。（私はこの理由が好きではありません...しかし、もしあなたがクローズドソースプロジェクトに取り組んでいるなら、テストコードはとにかく顧客を助けそうにないでしょう。）

現在、これらの問題のそれぞれに可能な回避策があります。しかし、IMO、そもそもそこに行かない方が簡単です。

初期の頃は、Javaプログラマーがこの種のことをしていたことを観察する価値があります。たとえば、main(...)テストを容易にするためにクラスにメソッドを含める。この考えはほぼ完全に消えました。ある種のテストフレームワークを使用してテストを個別に実装することは業界の慣例です。

また、Knuthが考案したLiterate Programmingがソフトウェアエンジニアリング業界で決して流行りませんでした。

実際、契約による設計はこれを行うと考えることができます。問題は、ほとんどのプログラミング言語では次のようなコードを記述できないことです:(手作業で前提条件をテストするのは非常に簡単ですが、コードを記述する方法を変更せずに後条件をテストするのは非常に困難です（巨大なネガティブIMO）。

Michael Feathersがこれについてプレゼンテーションをしています。これは、コードの品質を改善できると彼が言っている多くの方法の1つです。

コード内のクラス間の密結合を回避しようとする多くの同じ理由から、テストとコード間の不要な結合を回避することもお勧めします。

作成：テストとコードは、異なる人によって異なる時間に作成される場合があります。

制御：テストを使用して要件を指定する場合、実際のコードよりもいつ誰がそれらを変更できるかについてのさまざまなルールの対象にする必要があります。

再利用性：テストをインラインに配置すると、別のコードでテストを使用できなくなります。

あなたが正しく仕事をするコードの塊を手に入れたが、パフォーマンス、保守性、その他の面で望まれる多くのものを残していると想像してください。そのコードを新しく改善されたコードに置き換えることにしました。同じテストセットを使用すると、新しいコードが古いコードと同じ結果を生成することを確認できます。

選択可能性：テストをコードから分離しておくと、実行するテストを選択しやすくなります。

たとえば、現在作業中のコードにのみ関連するテストの小さなスイートと、プロジェクト全体をテストする大きなスイートがあるとします。

ここに私が考えることができるいくつかの追加の理由があります：

• 別のライブラリにテストがあると、そのライブラリのみをテストフレームワークにリンクし、本番コードにリンクするのが簡単になります（これは一部のプリプロセッサでは回避できますが、テストを記述するのが簡単なソリューションの場合にそのようなものをビルドする理由別の場所）

• 関数、クラス、ライブラリのテストは、通常、「ユーザー」の観点（その関数/クラス/ライブラリのユーザー）から作成されます。このような「コードを使用する」ことは通常、別のファイルまたはライブラリに記述され、その状況を模倣する場合、テストはより明確または「より現実的」になる場合があります。

テストがインラインの場合、顧客に製品を出荷するときにテストに必要なコードを削除する必要があります。そのため、テストを保存するための余分な場所は、必要なコードと顧客が必要とするコードを分離するだけです。

このアイデアは、オブジェクトベースまたはオブジェクト指向のデザインのコンテキスト内での「Self_Test」メソッドに相当します。Adaのようなコンパイルされたオブジェクトベースの言語を使用している場合、すべてのセルフテストコードは、プロダクションコンパイル中にコンパイラによって未使用（呼び出されない）としてマークされるため、すべて最適化されます-いずれにも表示されません結果の実行可能ファイル。

「Self_Test」メソッドを使用することは非常に良い考えであり、プログラマーが本当に品質に関心があるなら、彼らは皆それをやっているでしょう。ただし、重要な問題の1つは、「Self_Test」メソッドは実装の詳細にアクセスできず、代わりにオブジェクトの仕様内で公開されている他のすべてのメソッドのみに依存しなければならないという点で、厳格な訓練が必要なことです。明らかに、自己テストが失敗した場合、実装を変更する必要があります。セルフテストは、オブジェクトのメソッドの公開されたすべてのプロパティを厳密にテストする必要がありますが、特定の実装の詳細に決して依存しないでください。

オブジェクトベース言語とオブジェクト指向言語は、テスト対象オブジェクトの外部のメソッドに関してその種の規律を頻繁に提供します（オブジェクトの仕様を強制し、実装の詳細へのアクセスを防ぎ、そのような試みが検出された場合はコンパイルエラーを発生させます） ）。ただし、オブジェクト自体の内部メソッドには、すべての実装の詳細への完全なアクセス権が与えられます。そのため、セルフテストメソッドは固有の状況にあります。その性質上、内部メソッドである必要があります（セルフテストは明らかにテスト対象のオブジェクトのメソッドです）が、外部メソッドのすべてのコンパイラー規則を受け取る必要があります（オブジェクトの実装の詳細から独立している必要があります）。プログラミング言語がオブジェクトを統制する機能を提供している場合はほとんどありません」■外部メソッドであるかのように内部メソッド。したがって、これはプログラミング言語の重要な設計上の問題です。

適切なプログラミング言語のサポートがない場合、最適な方法は、コンパニオンオブジェクトを作成することです。つまり、コーディングするすべてのオブジェクト（「Big_Object」と呼びます）に対して、2番目のコンパニオンオブジェクトも作成します。その名前は、「実際の」オブジェクト（この場合は「Big_Object_Self_Test」）の名前と連結した標準接尾辞で構成されます"）、およびその仕様が単一のメソッドで構成されている（" Big_Object_Self_Test.Self_Test（This_Big_Object：Big_Object）return Boolean; "）。コンパニオンオブジェクトはメインオブジェクトの仕様に依存し、コンパイラはコンパニオンオブジェクトの実装に対してその仕様のすべての規則を完全に実施します。

これは、リリースビルドからテストコードを削除することが不可能であるため困難であるため、インラインテストが行​​われないことを示唆する多数のコメントへの応答です。これは真実ではありません。ほぼすべてのコンパイラとアセンブラは、C、C ++、C＃などのコンパイルされた言語でこれを既にサポートしています。これは、いわゆるコンパイラディレクティブで行われます。

c＃の場合（c ++でも、使用しているコンパイラに応じて構文が少し異なる可能性があります）、これがその方法です。

#define DEBUG //  = true if c++ code
#define TEST /* can also be defined in the make file for c++ or project file for c# and applies to all associated .cs/.cpp files */

//somewhere in your code
#if DEBUG
// debug only code
#elif TEST
// test only code
#endif

これはコンパイラディレクティブを使用するため、フラグが設定されていない場合、ビルドされる実行可能ファイルにはコードが存在しません。これは、複数のプラットフォーム/ハードウェア向けに「1回書き込み、2回コンパイル」プログラムを作成する方法でもあります。

Perlコードでインラインテストを使用します。インラインコードからテストファイルを生成するモジュールTest :: Inlineがあります。

私はテストを整理するのが特に得意ではありませんが、インライン化すると保守が容易になり、維持される可能性が高くなります。

提起されたいくつかの懸念への対応：

• インラインテストはPODセクションで記述されているため、実際のコードの一部ではありません。これらはインタプリタによって無視されるため、コードが肥大化することはありません。
• Vim折りたたみを使用して、テストセクションを非表示にします。あなたが見る唯一のものは、のようにテストされている各メソッドの上の単一行+-- 33 lines: #test----です。テストを使用する場合は、テストを展開するだけです。
• Test :: Inlineモジュールは、テストを通常のTAP互換ファイルに「コンパイル」するため、従来のテストと共存できます。

参考のため：

• POD
• TAP

Erlang 2は実際にインラインテストをサポートしています。使用されていないコード内のブール式（たとえば、変数に割り当てられた、または渡された）は、自動的にテストとして扱われ、コンパイラによって評価されます。式が偽の場合、コードはコンパイルされません。

テストを分離するもう1つの理由は、実際の実装よりもテスト用に追加のライブラリや異なるライブラリを使用することが多いことです。テストと実装を混在させると、実装でのテストライブラリの偶発的な使用をコンパイラがキャッチできなくなります。

また、テストは、テストする実装部分よりもコード行が多い傾向があるため、すべてのテスト間で実装を見つけるのに苦労します。:-)

これは真実ではありません。生産コードが特に生産ルーチンが純粋である場合、生産コードと一緒にユニットテストを配置することをお勧めします。

たとえば.NETで開発している場合、テストコードを製品アセンブリに配置し、Scalpelを使用してそれらを削除してから出荷することができます。