ユニットテストを別の言語で書く習慣がそれほど一般的ではないのはなぜですか。

Question

MicrosoftがVisual Studio 2008をリリースしたとき、彼らは会議やオンラインチュートリアルで多くのことを話していました。1つの言語で実際のコードを記述し、別の言語でユニットテストを書くというアイデアがありました。たとえば、C＃コードの単体テストはVisual Basicで記述できます。

6年後、私はこの手法を使用するオープンソースプロジェクトを知りません。この問題は、Microsoftの会議、ブログ、またはチュートリアルではもう議論されていません。

この方法の利点は、2つの異なる言語で同じタイプのエラーを実行することがより困難になることです。たとえば、C＃で10/3が3と等しいことを知らない場合、3.333...であることが期待されます。ユニットテストは、PythonまたはJavaScriptが失敗し、整数除算の発見につながります。

具体的には、.NET Frameworkを使用すると、.NET対応の言語を使用して別の言語をテストできます。 Visual BasicテストでC＃コードをテストすることはそれほど興味深いことではありませんが、両方の言語が類似していることを考えると、たとえば、C＃で記述された単体テストでF＃コードをテストすることは、あまり詳しくない人には役立つと思います関数型プログラミング。

個人的に、私は別の言語で単体テストを書いた経験がありません。したがって、この手法に実際の欠点があるかどうかはわかりません。私はしばしばシステムと受け入れテストを異なる言語で記述します（たとえば、Pythonの（Requests ライブラリーは非常に優れているので、Node.js WebアプリではPython）で）。これらのテストは本当に言語にとらわれないため、これはカウントされません。HTTPを介してブラックボックステストを実行するだけです。Node.jsからASP.NET MVCにアプリを書き直すことができ、テストは変更に気付くことさえありません。

それで、欠点は何ですか？なぜこの習慣がそれほど人気がないのですか？

user7043 · Accepted Answer

ユニットテストはホワイトボックステストであり、通常、テスト対象の開発者によって記述されます。 1つ目は、API、オブジェクト、および実際の製品が記述されている言語の値とのファーストクラスの相互作用が必要であることを意味します。これにより、ほとんどすべての言語の組み合わせが除外されます。実際、CLRは、それぞれが完全に相互に呼び出すことができる言語の唯一の集まりだと思います。そして、あなたが言うように、ほとんどのCLR言語は非常に似ているので、提案する利点はどれも適用されません。

F＃とC＃/ VB.NETの組み合わせだけが残ります。これがうまくいかなかったいくつかの理由が想像できます。

F＃にはそれほど大きなコミュニティはありません。逆に、ほとんどのC＃開発者は、これを検討するのに十分なF＃を知りません。
F＃を知っている人は、ユニットテストと実際のコードの両方をF＃で書くか、他の誰も知らないためにF＃をまったく使用できないチームで忙しいかのどちらかです（まあ）。前述のように、単体テストは通常、別のチームによって作成されるわけではないため、F＃コードのC＃単体テストを作成する人は、おそらくF＃を知っている必要があります。さらに、ホワイトボックス全体：関数型プログラミングについて知らない場合、「put」形式の非常に単純なライブラリよりも深く掘り下げると、（慣用的な）F＃によって公開されるデータ構造やAPIでさえ不自然になります。ここのURLで、IEnumerable<UrlParameter>。
メリットはありません（または人々がそのメリットを信じていません）が、おそらく言語を絶えず切り替えることによる非常に現実的な摩擦があります。

Martin Maat · Answer

私はそのようなプッシュを思い出しません。異なる言語を実際にテストして使用するのではなく、.NET空間での相互運用性のデモンストレーションであったと思います。このすばらしい共通言語ランタイム環境の利点を支えるためだけに、どんな利点も作られていました。

これは、ライブラリー・コードにとっては理にかなっていると思います。自分以外の.NET言語から使用される可能性が高い.NETライブラリを作成してデプロイすると、言語の使用など、クライアントコードとサーバーコードの両方が同じ言語である場合にのみ機能する機能を使用するという罠に陥る可能性があります。 CLRタイプだけではなく特定のタイプ。

jmoreno · Answer

IMOでこれがあまり見られなくなったのは、VBに釘を打つための別の方法だったからです。宣伝されているアイデアは、ユニットテストを別の言語で書くのが良いということではなく、VBコードのC＃ユニットテストを書くことができるということでした。

これにはいくつかの潜在的な利点があります。まず、チームにc＃の経験があまりない場合は、それを紹介する方法です。第二に、これは将来のプロジェクトへの扉を開くものです。つまり、すべてのコードはVBなので、次のプロジェクトはVBになり、最後のプロジェクト（単体テストプロジェクトですが、まだプロジェクトです）はC＃だったので、次のプロジェクトをC＃にしても問題ありません。事業。

それは2008年であり、2015年までには必要ありませんでした。まだVBを使用しているチームは、従来の理由でこれを引き続き使用しますが、ほとんどの新しい開発はC＃で行われます。