タイプされたJavaScriptの価値について、時(shí)々議論があります。 「もっとテストを書く！」一部の対戦相手は叫んだ。 「ユニットテストをタイプに置き換えてください！」他の人は叫んだ。どちらもいくつかの點(diǎn)で正しいものであり、他の點(diǎn)では間違っています。 Twitterのスペースは、微妙さを反映するのに十分ではありません。しかし、この記事では、この2つがどのようにどのように共存するかについての合理的な議論を詳しく説明しようとすることができます。

正しさ：私たちが本當(dāng)に欲しいもの

結(jié)果から始めるのが最善です。これらすべてのメタエンジニアリングから本當(dāng)に望んでいるのは正確さです。私は厳格な理論的なコンピューターサイエンスの定義に言及しているのではなく、プログラムの行動(dòng)とその規(guī)範(fàn)をより一般的に順守しています。プログラムがどのように機(jī)能するかについてのアイデアがあり、プログラミングプロセスがビットとバイトを整理し、このアイデアを?qū)g現(xiàn)します。私たちは常に自分が望むものを正確に知っているとは限らず、変更を加えるときにプログラムが壊れないことを確認(rèn)したいので、最初に物事を機(jī)能させるために、既存の元のコードの上にタイプとテストを書きます。

したがって、正しさが私たちが望むものであり、その種類とテストがこれを達(dá)成するための自動(dòng)化された方法であることを受け入れる場(chǎng)合、タイプとテストが正確性を達(dá)成するのに役立つ方法を示すための直感的なモデルを持つことをお?jiǎng)幛幛筏蓼埂?/p>

プログラムの正確性の視覚化モデル

プログラムが実行できるすべての操作（エラーを含む）が巨大な灰色の領(lǐng)域として実行できるすべての操作のすべての無限の完全なスペースを想像する場(chǎng)合、プログラムを?qū)g行したいもの、仕様は、その可能なスペースの非常に小さなサブセットです（下の図の緑の菱形は、何かを表示するためにサイズが誇張されています）：

プログラミングでの私たちの仕事は、プログラムを可能な限り仕様に合わせることです（もちろん、私たちは不完全であり、人間の誤り、新機(jī)能、または不特定の動(dòng)作のために、私たちの仕様は絶えず変化していることがわかります。

ここでの議論の目的のために、手続き的行動(dòng)の境界には計(jì)畫されたエラーと計(jì)畫外の両方のエラーも含まれることに注意してください。 「正しさ」の意味には、計(jì)畫されていないエラーではありませんが、計(jì)畫されていないエラーは含まれません。

テストと正確性

私たちのプログラムが私たちの期待を満たしていることを確認(rèn)するためにテストを書きますが、テストするものには多くのオプションがあります。

理想的なテストは、図のオレンジ色のドットです。プログラムが仕様と重複するかどうかを正確にテストします。この視覚化では、テストタイプを?qū)g際に區(qū)別するものではありませんが、ユニットテストを非常に小さなポイントと考えることができ、統(tǒng)合/エンドツーエンドのテストが大きなポイントです。いずれにせよ、それらはポイントです。なぜなら、プログラム內(nèi)のすべてのパスを完全に記述できるテストはないからです。 （実際、100％のコードカバレッジを使用できますが、爆発が組み合わされているため、すべてのパスをテストすることはできません！）

寫真の青い點(diǎn)は悪いテストです。もちろん、プログラムが機(jī)能するかどうかをテストしますが、実際には基礎(chǔ)となる仕様に固定していません（1日の終わりには、プログラムから本當(dāng)に取得したいこと）。このテストは、プログラムを修正して仕様とより密接に整合すると壊れ、偽陽性が得られます。

紫色のドットは、プログラムが機(jī)能するべきだと考える方法をテストし、プログラムが現(xiàn)在機(jī)能していない領(lǐng)域を決定するため、貴重なテストです。紫色のテストでリードし、それに応じてプログラムの実裝を修正することは、テスト駆動(dòng)型開発としても知られています。

寫真の赤いテストはまれなテストです。 「ハッピーパス」（計(jì)畫の間違った狀態(tài)を含む）をテストするのは、通常の（オレンジ）テストではなく、「不幸なパス」が失敗したことを期待して検証するテストです。このテストが「失敗する」場(chǎng)所に「合格」する場(chǎng)合、それは何かが間違っているという大きな早期警告サインですが、スペックグリーン領(lǐng)域の外に存在する大きな不幸なパスをカバーするのに十分なテストを書くことは基本的に不可能です。うまくいかないものをテストすることが価値があることを見つけることはまれです。したがって、彼らはそれをしません。しかし、物事がうまくいかない場(chǎng)合、それはまだ役立つ早期警告サインになる可能性があります。

タイプと正しさ

テストがプログラムが操作を?qū)g行できる可能性空間の単一のポイントである場(chǎng)合、このタイプは、パーツ全體を総確率空間から分割するカテゴリを表します。それらを長方形として視覚化することができます：

プログラムを表すダイヤモンドを比較するために長方形を選択します。なぜなら、タイプシステム自體がタイプを使用してプログラムの動(dòng)作を完全に説明できるためです。 （簡(jiǎn)単な例を示すために、常に正の整數(shù)である必要があるIDは數(shù)値タイプですが、數(shù)値タイプも分?jǐn)?shù)と負(fù)の數(shù)を受け入れます。數(shù)値リテラルの非常に単純な結(jié)合を除けば、數(shù)値タイプを特定の範(fàn)囲に制限することは不可能です。）

タイプは、コードを書くときにプログラムが実行できる場(chǎng)所の制約として機(jī)能します。プログラムがプログラムタイプの指定された境界を超え始めた場(chǎng)合、タイプチェッカー（TypeScriptやFlowなど）は、単にプログラムのコンパイルを許可することを拒否します。これは良いことです。なぜなら、JavaScriptのような動(dòng)的な言語では、確かに作成したくないクラッシュプログラムを誤って作成できるからです。最も簡(jiǎn)単な付加価値は、自動(dòng)ヌル値チェックです。 fooにbarという名前のメソッドがない場(chǎng)合、foo.bar（）を呼び出すと、よく知られていない未定義が機(jī)能することは機(jī)能の例外ではありません。 FOOが完全に入力されている場(chǎng)合、執(zhí)筆時(shí)點(diǎn)でタイプチェッカーでこの問題をキャッチし、コードの問題のある行を指摘することができます（および自動(dòng)コンプリートの伴う利點(diǎn)があります）。これは、テストができないことです。

まるで私たちの仕様に適合している可能性のある長方形をできるだけ小さな長方形に書こうとしているかのように、プログラムの厳格なタイプを書きたいと思うかもしれません。ただし、タイプシステムを活用するには、完全に新しい構(gòu)文と演算子と、JavaScriptの完全なダイナミックレンジをシミュレートするために必要な一般的なタイプロジックの構(gòu)文を?qū)W習(xí)することが含まれるため、これには學(xué)習(xí)曲線があります。マニュアルとチートシートは、學(xué)習(xí)曲線を下げるのに役立ち、ここでより多くの投資が必要です。

幸いなことに、この採用/學(xué)習(xí)曲線は私たちを止める必要はありません。タイプチェックは、フローのオプションのプロセスであり、タイプスクリプトの構(gòu)成可能なストリンジェンシー（問題のコードのラインを選択的に無視する機(jī)能）であるため、タイプの安全性の範(fàn)囲內(nèi)から選択できます。これをモデル化することもできます：

上記の畫像の大きな赤い長方形のように、より大きな長方形は、コードベースのタイプシステムの非常にゆるい採用を示しています。たとえば、インクリティニーを許可し、タイプの推論に完全に依存して、プログラムを最悪のコーディングから単純に制限します。

中程度のストリンジェンシー（中型の緑の長方形など）は、より忠実なタイプ化を示すことができますが、コードベース全體で明示的なインスタンスや手動(dòng)型アサーションを使用するなど、多くの脆弱性があります。それにもかかわらず、このような軽量のタイピング作業(yè)が実行されたとしても、仕様と一致しない効果的なプログラムの可能な表面積は大幅に削減されます。

紫色の長方形のような最大の厳密さは、物事を非常にきつくするため、プログラムの不適合な部分を見つけることがあります（通常、プログラムの動(dòng)作における予定外のエラーです）。このような既存のプログラムでエラーを探すことは、通常のJavaScriptコードベースを変換するチームで非常に一般的なケースです。ただし、タイプチェッカーから最大タイプの安全性を取得するには、各変數(shù)と機(jī)能の可能なタイプスペースを改良および絞り込むように設(shè)計(jì)された一般的なタイプと特別な演算子を活用する必要があります。

タイプを書く前にプログラムを作成する必要はないことに注意してください。結(jié)局のところ、タイプが仕様を密接にシミュレートすることを望んでいるので、実際にタイプを最初に記述してから、後で実裝を入力できます。理論的には、これはタイプ駆動(dòng)型開発です。実際には、実際のプログラムコードにタイプが浸透してインターワインするため、実際にこのように開発する人はほとんどいません。

それらをまとめてください

最終的に構(gòu)築したいのは、プログラムの正確性を確保するためにタイプとテストが互いに補(bǔ)完する方法を示す直感的な視覚化です。

私たちのテストは、私たちのプログラムが選択された臨界パスで予想どおりに特別に実行されることを主張しています（ただし、上記のように、特定の他のテストバリアントがありますが、テストの大部分はそうしています）。私たちが開発した視覚言語では、プログラムの濃い緑色の菱形を標(biāo)準(zhǔn)的な薄緑色の菱形に「修正」します。プログラムの動(dòng)きはこれらのテストを破壊し、警告を発します。それは素晴らしい！テストには、最もカスタマイズされたユースケースの無制限の柔軟性と構(gòu)成性もあります。

私たちのタイプは、私たちのプログラムが、できるだけ密接に仕様を囲むことを望んで、私たちが描いた境界を越えて可能な障害モードを禁止することによって私たちの制御不能にならないと主張しています。私たちの視覚言語では、彼らは標(biāo)準(zhǔn)から逸脫するプログラムの可能性のあるドリフトを「封じ込め」（私たちは常に欠陥があり、私たちが犯すすべての間違いはプログラムに追加の障害を追加するからです）。タイプも鈍いですが、（推論とエディターツールのタイプのため）、ゼロから書く必要のないタイプを提供する強(qiáng)力なコミュニティから利益を得る強(qiáng)力なツールです。

要するに：

• テストは、幸せな道が機(jī)能するようにするのに最適です。
• タイプは、不幸なパスが存在するのを防ぐのに最適です。

最良の結(jié)果を得るために、それらの強(qiáng)みに従ってそれらを一緒に使用してください！

タイプとテストがどのように交差するかについて詳しく知りたい場(chǎng)合、ゲイリー?ベルンハルトの境界に関する素晴らしいスピーチとケント?C?ドッズのテストトロフィーは、この投稿についての私の考えに大きな影響を與えました。

以上がタイプまたはテスト：両方ではないのはなぜですか？の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國語 Web サイトの他の関連記事を參照してください。