4
静的型付け機能コードの単体テスト
haskell、scala、ocaml、nemerle、f#、またはhaXeで記述された静的に型付けされた機能コードを単体テストするのが理にかなっています(最後は本当に興味のあることですが、より大きなコミュニティの知識を活用してください)。 私の理解から: 単体テストの1つの側面は、仕様を実行可能な形式にすることです。ただし、形式化された仕様を言語セマンティクスに直接マップする宣言スタイルを使用する場合、実際に仕様を実行可能な形式で別の方法で表現することもできますか? 単体テストのより明白な側面は、静的分析では明らかにできないエラーを追跡することです。型安全機能コードは、静的アナライザーが理解するものに非常に近いコードを作成するための優れたツールであることを考えると、多くの安全性を静的分析にシフトできるように思われます。ただし、コードxでy(両方とも座標)の代わりに使用するような単純なミスはカバーできません。OTOHこのような間違いは、テストコードの作成中にも発生する可能性があるため、努力する価値があるかどうかはわかりません。 ユニットテストでは冗長性が導入されます。つまり、要件が変更された場合、それらを実装するコードとこのコードをカバーするテストの両方を変更する必要があります。もちろん、このオーバーヘッドはほぼ一定であるため、実際には問題ではないと主張することができます。実際、Rubyのような言語では実際には利点と比較されませんが、静的に型指定された関数型プログラミングが地上ユニットテストの多くを対象としていることを考えると、ペナルティなしで単純に削減できる一定のオーバーヘッドのように感じます。 このことから、このプログラミングスタイルでは単体テストはやや時代遅れであると推測します。もちろん、そのような主張は宗教的な戦争につながる可能性があるため、簡単な質問に要約します。 このようなプログラミングスタイルを使用する場合、単体テストをどの程度使用し、その理由は何ですか(コードでどの程度の品質を得たいと考えていますか)。または、逆に、静的アナライザーでカバーされているため、ユニットテストのカバレッジを必要とせずに、静的に型指定された機能コードのユニットを修飾できる基準はありますか?