通过对几百行F＃代码进行单元测试，我意识到不仅要检查输出而且要检查签名是有利的。 原因是如果代码被验证用于发布，然后在修改签名的发布之后进行更改，则可能想知道签名发生更改的原因，以便可以为新签名更新测试用例或标记改变导致问题。
是否可以创建一个测试用例来验证签名？ 如果是这样，怎么样？
With unit-testing several hundred lines of F# code I realized that it would be advantageous to not only check the output but also the signatures. The reason being if the code is validated for a release and then changes are made after the release that modify the signature, one would want to know why the signature changed so that either the test case can be updated for the new signature or to flag the change as causing a problem.
Is it possible to create a test case to verify a signature? If so, how?
最满意答案
正如斯蒂芬所说，如果你为你的代码编写了一些单元测试，单元测试通常会调用函数所需类型值的函数，这样就会自动检查签名（如果更改了签名，你将会无法编译您的测试）。
另一种适用于库的替代方法是使用F＃接口文件（ .fsi ）。 接口文件指定实现文件（ .fs ）中的公共函数类型，它也是文档的好地方。
如果您（意外地）更改了实现的类型，则除非更新接口文件中的类型，否则代码将无法编译。
您可能希望手动维护接口文件（有关示例，请参阅F＃库源），但您可以通过使用--sig:mylibrary.fsi调用编译器来--sig:mylibrary.fsi 。 您可以使用此开关自动执行测试（并在每次编译后检查签名文件之间的差异）。
As said by Stephen, if you write some unit tests for your code, the unit tests will generally call the function with values of the type that the function require, so that will automatically also check the signature (if you change the signature, you will not be able to compile your tests).
Another alternative, which is suitable for libraries is to use F# interface files (.fsi). The interface file specifies types of public functions in the implementation file (.fs) and it is also a good place for documentation.
If you then (accidentally) change the type of your implementation, your code will not compile unless you update the type in the interface file.
You will probably want to maintain the interface file by hand (see F# library sources for a good example), but you can get an initial by calling the compiler with --sig:mylibrary.fsi. You could probaby use this switch to automate the testing (and check the diff between signature files after each compilation).
更多推荐
发布评论