私はただ疑問に思っています—プログラミング言語機能はユニットテストされていますか?
もしそうなら—
言語は通常テストされませんが、実装は非常に徹底的にテストされることがよくあります。非常に基本的なインフラストラクチャとして、それらは動作する必要があります。ただし、機能を個別にテストすることはできないため、言語の単体テストは困難です。 「ユニット」を区切る方法はありません。言語のさまざまな機能には、豊富で複雑な相互作用があり、テストケースに必要な有効なプログラムは、その特定のテストの目的ではない多くのことに必ず触れます。
このようなテストは統合テストです。プログラム全体が実行され、特定の出力が生成されることが期待されています。多くの場合、言語インフラストラクチャには、これを管理するためのカスタムテストランナーが含まれています。例えば。 TAPテスト結果のフォーマットは、初期のPerlインタープリターテストケースから始まりました。
新しいテストケースの主な原因は、多くの場合、回帰テストです。ユーザーが問題を見つけたので、再度修正する必要がないことを確認したいと考えています。一部の言語は、参照実装(Ruby、Perl、Pythonなど)によって効果的に定義されています。言語は、リファレンス実装が行うことです。これはテストを少し無意味にします。ただし、完全なテストスイートを使用して、互換性のある代替実装を作成できます。
多くの言語は仕様によって定義されています。仕様を直接テストまたは検証することはできません。通常、この言語は、正式化される前に、少なくともプロトタイプまたは参照実装にすでに存在しています。興味深い反例はPerl6です。Perl6では、(非公式の)仕様が、実装が存在する前に一連のテストケースに変換されました。これにより、潜在的な実装の進行状況を非常に視覚的に追跡できるようになりました。まだ実装されていない言語機能をすぐに確認できます。 Javaにも正規のテストスイートがありますが、これはJava言語仕様よりもJava商標に関連しています。
パーサーにとって、ファズテストは非常に価値があります。これは実際には言語をテストしませんが、実装が適切に動作し、防御的プログラミングを使用していることを確認します。ここでは、実装への入力はランダムに変更されます。通常、これらの変更により構文が不正になるため、エラーメッセージと正常な終了が期待されます。実装内のエラーがトリガーされた場合、可能性のあるバグを示している可能性が高いため、テスト入力は人間による確認のために保存されます。