7

関連する質問をしましたが、満足のいく回答が得られませんでした。だから、おそらく私はそれを別の方法で尋ねるべきです。

PerlやRuby、さらにはLinuxカーネルなどの大規模なCプロジェクトは、ユニットテストをどのように処理しますか？または、関数型言語でも？

私はOOPでのテストのための依存性注入と抽象ファクトリに精通していますが、非OOPでのスケーラブルで管理しやすい同等性は見当たりません。たとえば、CやHaskellでは、関数のレイヤーの上にレイヤーがあり、上位のレイヤーは暗黙的に下位のレイヤーを呼び出します。すべての依存関係ではなく、コードの単位だけをテストするための継ぎ目を見つけるにはどうすればよいですか？

シームの必要性をすべて一緒に回避する1つの方法は、呼び出し依存グラフの深さを非常に低く保つことです。いわば、垂直方向ではなく水平方向にコーディングします。「leaf」関数で可能な限り多くのアプリケーションロジックを保持します。そして、「ノード」関数が他のノード/リーフ関数にデータを配管する以外に機能しないことを確認してください。次に、「リーフ」機能のみをテストします。「ノード」機能は統合テストに任せてください。そのアプローチは効果的ですか？

今日の最大のソフトウェアは、今でも手続き型言語で書かれています。うまくいくいくつかの方法論が採用されているに違いありません。優れたユニットテストを備えた手続き型言語の大規模ソフトウェアの経験がある人はコメントできますか？

4

2 に答える 2

5

関数型言語には、MLファンクターなど、モジュール性のための他の構造（オブジェクト以外）があります。「依存性注入」は、基本的に「物事を抽象化する」の栄光の名前であり、関数型言語で長年使用されてきました。

すべてのパラダイムで、テストは仕様の境界に従う必要があります。特定のコード（関数、メソッド、オブジェクトなど）が何をするのかがわかっている場合は、この仕様に照らしてテストする必要があります。リーフ関数の場合、これは単体テストになります。「ノード」関数の場合、これは必要に応じて「統合テスト」と見なすことができますが、実際には同じアクティビティです。

同じ方法論が関数型プログラミングに本質的に適用され、本質的に同じ結果が得られることがわかると思います。特に、テストが容易になるようにコードを（再）設計すると、モジュール性と保守性も向上します。

于 2011-04-06T14:53:50.180 に答える
1

テストが容易になるようにコードを設計すると、モジュール性と保守性も向上します。

違います。テストしやすいようにコードを設計すると、テストコードの記述が容易になります。

機能モジュールの自然な分割は、通常、単体テストに最も便利ではありません。そのため、最近の多くのJavaコードは、小さな散在する部分に分割されており、各部分はそれ自体ではほとんど役に立ちません。

于 2011-08-08T21:31:55.803 に答える