言語のテストが構文レベルでサポートされている機能ではないのはなぜですか？

ソースコードの単体テストの利点を宣伝するブログ、記事、ウェブサイトの無限のリストを見つけることができます。Java、C ++、C＃、およびその他の型付き言語用のコンパイラをプログラムした開発者は、ユニットテストを使用して作業を検証したことがほぼ保証されています。

それでは、なぜその人気にもかかわらず、これらの言語の構文にテストがないのでしょうか？

マイクロソフトはC＃にLINQを導入しましたが、なぜテストも追加できないのですか？

私は、これらの言語の変更がどうなるかを予測するつもりはありませんが、そもそもなぜそれらが変更されないのかを明確にするつもりです。

例として：ステートメントのfor構文なしでループを書くことができることを知っていますfor。whileまたはif/ gotoステートメントを使用できます。誰かがfor声明がより効率的であると判断し、それを言語に導入しました。

テストがプログラミング言語の同じ進化に従っていないのはなぜですか？

多くの場合と同様に、ユニットテストは言語レベルではなくライブラリレベルで最適にサポートされます。特に、C＃には多数の単体テストライブラリが用意されているほか、.NET FrameworkのネイティブなものもありますMicrosoft.VisualStudio.TestTools.UnitTesting。

各単体テストライブラリには、テストの哲学と構文が多少異なります。すべてのものが平等であり、選択肢が多ければ少ないほど良い。単体テストが言語に組み込まれている場合、言語設計者の選択に縛られるか、ライブラリを使用して、言語テスト機能を完全に使用しないようにします。

例

• Nunit -C＃の言語機能を最大限に活用する、汎用的で慣用的に設計された単体テストフレームワーク。

• Moq-記録/再生のメタファーなしで、ラムダ式と式ツリーを最大限に活用するモックフレームワーク。

他にも多くの選択肢があります。Microsoft Fakesのようなライブラリは、インターフェイスや仮想メソッドを使用してクラスを記述する必要のない「シム...」モックを作成できます。

Linqは言語機能ではありません（名前にもかかわらず）

Linqはライブラリ機能です。ラムダ式や拡張メソッドなど、C＃言語自体に無料で多くの新機能が追加されましたが、Linqの実際の実装は.NET Frameworkにあります。

linqステートメントをよりクリーンにするためにC＃に追加された構文糖がいくつかありますが、その糖はlinqを使用するために必須ではありません。

理由はたくさんあります。Eric Lippertは、理由feature XはC＃にないのは、予算にないからだと何度も述べています。言語設計者には、物事を実装するための無限の時間もお金もありません。また、各新機能には、それに関連するメンテナンスコストがあります。言語をできる限り小さく保つことは、言語設計者にとってだけでなく、代替の実装やツール（IDEなど）を作成する人にとっても簡単です。無料で移植可能。単体テストがライブラリとして実装されている場合、一度だけ記述するだけでよく、言語の準拠する実装で機能します。

Dには単体テストの構文レベルのサポートがあることに注意してください。彼らがなぜそれを投入することにしたのかはわかりませんが、Dが「高レベルのシステムプログラミング言語」であることを意図していることは注目に値します。設計者は、C ++が伝統的に使用されてきた、安全ではない低レベルのコードに対して実行可能であることを望んでいました。そのため、いくつかの安全でないコードが機能することを確認するのに役立つものに余分な労力を費やすことは、彼らにとって理にかなっていると思います。たとえば、特定の信頼できるモジュールのみが、未チェックの配列アクセスやポインター演算などの安全でない操作を実行できるように強制できます。

また、迅速な開発も優先事項であったため、Dコードをスクリプト言語として使用できるようにコンパイルするのに十分な速度でコンパイルするという設計目標を達成しました。ユニットテストを言語に直接ベイクして、追加のフラグをコンパイラに渡すだけでテストを実行できるようにします。

ただし、優れた単体テストライブラリは、いくつかのメソッドを見つけて実行するだけではありません。HaskellのQuickCheckを例にとると、f (x, y) == f (y, x)「すべてのxとyについて」などをテストできます。QuickCheckはユニットテストジェネレーターとして記述される方が適切であり、「この入力に対して、この出力を期待しています」よりも高いレベルでテストすることができます。QuickCheckとLinqの違いはそれほどありません。どちらもドメイン固有の言語です。ユニットテストのサポートを言語に追加するのではなく、DSLを実用的にするために必要な機能を追加してみませんか？ユニットテストだけでなく、結果としてより良い言語になります。

テスト、特にテスト駆動開発は、直感に反する現象であるためです。

ほとんどすべてのプログラマーは、実際よりも複雑さの管理がはるかに優れていると信じてキャリアを開始します。偉大なプログラマーでさえ、多くの回帰テストを使用しない限り、重大なエラーなしに大きく複雑なプログラムを書くことができないという事実は、多くの実践者にとって非常に残念であり、恥ずべきことですらあります。したがって、すでによく知っているはずの専門家の間でも、定期的なテストに対する一般的な傾向。

宗教的なテストが徐々に主流になり、期待されているという事実は、ストレージ容量とコンピューティング能力の爆発的増加により、これまでよりも大きなシステムが構築されているという事実によるものだと思います-非常に大規模なシステムは、特に複雑さの崩壊に陥りやすい回帰テストのセーフティネットなしでは管理できません。その結果、特に頑固で妄想した開発者でさえ、テストが必要であり、常にテストが必要であることを不承不承に認めています（これがAAミーティングでの告白のように聞こえる場合、これは非常に意図的です-セーフティネットの必要性は多くの人々にとって心理的に難しい個人）。

今日人気のあるほとんどの言語は、この態度が変わる前のものであるため、テストのサポートはほとんど組み込まれてassertいません。傾向が続く場合、将来の言語はライブラリレベルではなく、その言語でより多くのサポートを受けると確信しています。

多くの言語がテストをサポートしています。Cのアサートは、プログラムが失敗する可能性があるテストです。ここでほとんどの言語が停止しますが、エッフェルと最近のAda 2012には前不変式（関数への引数が渡す必要があるもの）と後不変式（関数の出力が渡す必要があるもの）があり、Adaはポストインバリアント。Ada 2012は型不変条件も提供するため、メソッドがAdaクラスで呼び出されるたびに、戻り前に型不変条件がチェックされます。

これは、優れたテストフレームワークが提供できる完全なテストの種類ではありませんが、言語が最適にサポートできる重要な種類のテストです。

強く型付けされた関数型言語の支持者の中には、これらの言語機能が単体テストの必要性を低減または排除すると主張する人もいます。

これの良い例は、F＃for Fun and Profitのこちらとこちらです

個人的には、私はまだ単体テストの価値を信じていますが、いくつかの有効なポイントがあります。たとえば、違法な状態がコードで表現できない場合、この場合の単体テストを書く必要がないだけでなく、不可能です。

ユニットテストに関しては強調されていないので、必要ないくつかの機能の追加を逃したと主張します。

たとえば、C＃の単体テストは、主に属性を使用して実行されます。カスタム属性機能は、のようなもので、NUnitのようなフレームワークは、反復と競合することを可能にする豊富な拡張機構を提供理論をベースとパラメータ化テストを。

これは私の2番目の主要なポイントに私を連れて行きます-私たちは言語にそれを焼くために良いテスト容易性を作るものについて十分に知りません。テストにおける革新のペースは他の言語構成よりもはるかに速いため、革新の自由を残すために、言語に柔軟なメカニズムを持たせる必要があります。

私はユーザーですが、TDDに夢中ではありません-場合によっては、特にデザイン思考を改善するのに非常に役立ちます。大規模なレガシーシステムには必ずしも有用ではありません。優れたデータと自動化による高レベルのテストは、強力なコード検査文化とともに、より多くの利益をもたらすでしょう。

その他の関連資料：

• 50年の言語の設計
• テスト可能なように設計された言語に関する以前のSO質問
• エッフェル自動テスト