動的なタイピングを補うための非セマンなテストにうんざりしていません - 提案？

Question

コンピューターエンジニアリングの調査を開始する前に、私はレールで多くのWebプログラミング（その前にPHP）を行っていました。

それ以来、私はCで多くの学校の仕事をし、Objective-C（Mac Stuff）で個人的なものをいくつかしました。静的タイピングが大好きであることを学びました。

しかし今、私はいくつかのプロのウェブ開発（フリーランス）を行う必要があり、再びレールを拾いました。私は、非セマンチックなタイプチェックテストを書くのは本当に迷惑だと感じています。私はそれらをCやObjective-Cコンパイラから無料で手に入れていました。ビルドを押して、システムにすべてのコードをチェックして、AがBを呼び出すことができることを確認するのが大好きでした。しかし、Railsでは、私はコンパイラです。 :(

誰かがこの同じ道を踏んだことがありますか？ C＃およびJava + Xフレームワークを備えたWeb開発ASP.NET MVCの唯一のオプションですか？いくつかの提案を探している、またはいくつかの同情さえ...：P

ちなみに、私はルビーではなくレールに具体的な参照をします。なぜなら、私はスクリプトなどの単純なものに対してルビーのダイナミックな性質を気にしないからです。しかし、レールは非常に多くの宝石に依存しており、通常は他の多くの宝石を追加するため、動的なタイピングが問題になります。

ありがとう！

編集：

私はPSTの提案をフォローアップし、Scalaを調べました。言語の作成者であるMartin Oderskyによって書かれたScalaでの本のプログラミングを読んで、私は多くの点で私の懸念ともう少しを表現するこのテキストを受け入れました。非常に興味深い読書。

ScalaでのMartin Oderskyのプログラミングの52ページから撮影：

Scalaは静的に型付けされています

静的タイプシステムは、それらが保持および計算する値の種類に従って変数と式を分類します。 Scalaは、非常に高度な静的タイプシステムを備えた言語として際立っています。 Javaのようなネストされたクラスタイプのシステムから始めて、ジェネリックを使用してタイプをパラメーター化したり、交差点を使用してタイプを組み合わせたり、抽象型を使用してタイプの詳細を隠すことができます。これらは、独自のタイプを構築して作曲するための強力な基盤を提供し、同時に使用しやすく柔軟なインターフェイスを設計できるようにします。

Perl、Python、Ruby、Groovyなどの動的な言語が好きなら、Scalaの静的タイプシステムがその長所の1つとしてリストされていることは少し奇妙に感じるかもしれません。結局のところ、静的タイプシステムの欠如は、動的言語の主要な利点として一部のものによって引用されています。静的タイプに対する最も一般的な議論は、プログラムをあまりにも冗長にし、プログラマーが望むように自分自身を表現することを妨げ、ソフトウェアシステムの動的な変更の特定のパターンを不可能にすることです。

ただし、多くの場合、これらの議論は、一般的な静的タイプのアイデアに反するのではなく、特定のタイプシステムに反するものであり、冗長であるか、柔軟性が高すぎると認識されています。たとえば、SmallTalk言語の発明者であるAlan Kayはかつて次のように述べていました。「私はタイプに反対していませんが、完全な痛みではないタイプのシステムを知りません。

この本で、Scalaのタイプシステムは「完全な痛み」にはほど遠いことをあなたに納得させたいと思っています。実際、静的タイピングに関する通常の懸念のうち2つに適切に対処します。タイプの推論によって冗長性が回避され、パターンマッチングといくつかの新しい方法を介して柔軟性が得られます。これらの障害が邪魔にならないため、静的タイプシステムの古典的な利点をよりよく評価することができます。これらの利点の中で最も重要なのは、プログラムの抽象化、安全なリファクタリング、およびより良いドキュメントの検証可能な特性です。

検証可能なプロパティ

静的タイプシステムは、特定の実行時間エラーがないことを証明できます。たとえば、彼らは次のような特性を証明できます。ブーリアンは整数に追加されることはありません。プライベート変数は、クラスの外部からアクセスされません。関数は、適切な数の引数に適用されます。文字列のみが一連の文字列に追加されます。

他の種類のエラーは、今日の静的タイプシステムでは検出されません。たとえば、それらは通常、非終了関数、配列の境界違反、またはゼロによる分割を検出しません。また、プログラムがその仕様に準拠していないことも検出されません（スペックがあると仮定します！）。したがって、静的型システムは、あまり役に立たないものとして却下されています。このようなタイプのシステムは単純なエラーのみを検出できるのに対し、単体テストはより広範なカバレッジを提供するのは、なぜ静的なタイプを悩ませるのかという議論はありますか？

これらの議論はポイントを見逃していると信じています。 静的タイプシステムは確かに単体テストを置き換えることはできませんが、そうでなければテストする必要があるいくつかのプロパティを処理することで必要な単体テストの数を減らすことができます。 同様に、ユニットテストは静的タイピングを置き換えることはできません。結局のところ、Edsger Dijkstraが言ったように、テストはエラーの存在を証明するだけでなく、決して不在ではありません。したがって、静的タイピングが与える保証は単純かもしれませんが、それらはテストの量が提供できない形式の本当の保証です。

安全なリファクタリング

静的タイプシステムは、セーフティネットを提供し、自信を高めてコードベースに変更を加えることができます。たとえば、メソッドに追加のパラメーターを追加するリファクタリングを検討してください。静的にタイプされた言語では、変更を行い、システムを再コンパイルし、タイプエラーを引き起こすすべての行を単純に修正できます。これを終えたら、変更する必要があるすべての場所を見つけることができます。メソッド名の変更や、あるクラスから別のクラスへのメソッドの移動など、他の多くの単純なリファクタリングについても同じことが当てはまります。すべての場合において、静的タイプチェックは、新しいシステムが古いものと同じように機能するという十分な保証を提供します。

ドキュメンテーション

静的タイプは、コンパイラが正しさを確認するプログラムドキュメントです。通常のコメントとは異なり、タイプの注釈は時代遅れになることはありません（少なくとも、最近コンパイラに合格したソースファイルが含まれている場合）。さらに、コンパイラと統合開発環境は、タイプの注釈を利用して、より良いコンテキストヘルプを提供することができます。たとえば、統合された開発環境は、選択が行われた式の静的なタイプを決定し、そのタイプのすべてのメンバーを検索することにより、選択に利用できるすべてのメンバーを表示できます。

Answer 1

これは、動的言語に関する私の「グリップ」の1つです。タイプのエラーではなくセマンティクスをテストしたい;-)言われていることは、すべての非自明の状況で本当に必要なものであり、優れたコードカバレッジとテストされた要件が重要であることが重要です。

JVMの静的タイピングパスを下りたい場合（私は持っています）、私は見ることを強くお勧めします スカラ. 。 Rubyから来ると、Javaに行くよりもはるかに痛みが少なくなります（実際にはさまざまな方法で多くの楽しみがあります）。あなたは、あなたが当たり前のことを「保持する」ことができます - 式ベースの構文、閉鎖、多くの場所でタイプを省略する機能（Rubyほどオープンではありませんが、コンパイル時間タイプチェックを取得します;-)、すべて（*） - オブジェクトOO、統一されたアクセサの方法、DSLSを簡単に構築する能力、および砂糖を作成し、ローカルタイプの推論、パターンマッチング、比較的豊富なコレクションフレームワーク、および静的にタイプされた言語の利点を得ることができます。 Javaとの適切な統合（多数のWebフレームワークを含む、SCALA言語を活用するSCALA固有のフレームワークもいくつかあります）。

c＃3.0/4.0（および.net3.5+）はそうではありません ぼろぼろ どちらか（ただし、C＃2.0は避けてください。これは現在、リコンです）、Linq/閉鎖の導入、基本的なタイプの推論、その他の素晴らしい言語機能により、ほとんどのタスクで「許容可能」になります（Javaを評価する方法を推測してください言語として;-)。ただし、C＃はCLRターゲット言語です（.NET Scalaポートがありますが、ステータスはわかりませんが、メインのターゲットプラットフォームではありません）。

Scalaについて言及したので、ocamlに似ている「functional with oo」アプローチをとるF＃（現在は「公式」.net言語）に言及する必要があります。機能的で」。 C＃WRT The Type Systemと比較して、F＃に対する/反対の議論を聞いたことがありますが、F＃での実際の経験はありません。パラダイムのシフトが気に入るかもしれないし、そうでないかもしれません。

ハッピーコーディング。

Answer 2

あなたがRailsに言及し、あなたがScalaに興味を持っていることを考えると、あなたは絶対にチェックする必要があります リフト. 。これが次のとおりです 2008年のインタビュー その作成者と、a 2009年のプレゼンテーション （ビデオ）、これは古いものの、他の言語の代替品とリフトを比較するためです。

しかし、リフトがあなたのものではない場合は、あることを安心させてください 他のScala Webフレームワーク.

Answer 3

このタイプのテストは、通常、レールでは行われません。それをしなければならないことに悩まされる代わりに、それについて心配しないでください。または、ほとんどのRailsプログラマーはそうではないので、おそらくそれが問題だと思う理由を説明するより良い仕事をするでしょう。

アップデート

書いた人 test_include_with_order_works この特定のケースの文字列と同じシンボルを解釈することを確認しています。 Railsはすでにこの機能を提供し、テストしているため、テストしなければならないもののようには見えません。率直に言って、私は誰もがシンボルが文字列のように機能するかどうかを心配することさえあることに少し驚いています。私たちは皆、それができること、そしてしばしばそうすることを知っています。

一般に、Railsフレームワークは、その実装がその設計に適合するように、そうでないことを確実にしなければならないと思います。動的にタイプされた言語での実用的な哲学は、クライアントコードが呼び出している方法を破るパラメーターを渡さないということだと思います。もしそうなら、彼らはメソッドを呼び出すことから使われません。メソッドがあまりにも多くのパラメーターを提供されている場合、メソッドが特別なパラメーターを簡単に無視できる場合に、メソッドが例外をスローするように時間を無駄にする必要はありません。

したがって、あなたが提供した例が、レールでの非セマンチックなテストの必要性を実際に示しているかどうかはわかりません。