数百行のF＃コードの単体テストで、出力だけでなく署名もチェックすることが有利であることに気付きました。その理由は、コードがリリースに対して検証され、リリース後に署名を変更する変更が行われた場合、テストケースを新しい署名用に更新できるように、または署名にフラグを立てるために、署名が変更された理由を知りたい場合があります。問題の原因として変更します。
署名を検証するためのテストケースを作成することは可能ですか？もしそうなら、どのように？
質問する
193 次
2 に答える
2
最善のアプローチは、署名の範囲をカバーするテストケースを提供することだと思います。たとえば、リターンタイプが、であることを確認するにはint、
let x:int = someFunc() //you'll get a compiler error if the return type changes
実際、パブリックAPIを徹底的にテストするだけで、必ず署名をテストしていると思います。特に、比較的厳密な静的型システムを持つF＃のような言語では。
リフレクションを使用して署名をアサートすることもできると思いますが、正直なところ、それはそれほど時間の投資になるとは思いません。
于 2012-10-01T15:15:30.143 に答える
2
Stephenが言ったように、コードの単体テストを作成する場合、単体テストは通常、関数が必要とするタイプの値を使用して関数を呼び出すため、署名も自動的にチェックされます（署名を変更すると、テストをコンパイルできません）。
ライブラリに適したもう1つの方法は、F＃インターフェイスファイル（.fsi）を使用することです。インターフェイスファイルは、実装ファイル（.fs）でパブリック関数のタイプを指定します。また、ドキュメントを作成するのにも適しています。
その後、（誤って）実装のタイプを変更した場合、インターフェイスファイルのタイプを更新しない限り、コードはコンパイルされません。
インターフェイスファイルを手動で管理することをお勧めします（良い例については、F＃ライブラリのソースを参照してください）が、。を使用してコンパイラを呼び出すことでイニシャルを取得できます--sig:mylibrary.fsi。このスイッチを使用して、テストを自動化できます（また、コンパイルごとに署名ファイル間の差分を確認できます）。
于 2012-10-01T15:54:37.127 に答える