单元测试通常与软件版本一起部署以验证安装 - 即执行安装，运行测试，如果它们通过则安装良好。
我即将开始一个涉及向客户提供原型软件库发布的项目。单元测试将作为每个版本的一部分提供，除了使用测试来验证安装之外，我还计划使用测试API的单元测试作为如何使用发布的“合同”。如果用户使用该版本的方式与单元测试的使用方式类似，那么很好。如果他们以其他方式使用它，那么所有的赌注都会被取消。
以前有人试过这个吗？是否这是一个好/坏的想法？
编辑：为了突出ChrisA和Dan在下面的回复中提出的一个好点，“测试API的单元测试”更好地称为集成测试，他们的意图是运用API和软件来演示功能从客户的角度来看软件。
答案 0 :(得分：11)
对我来说听起来不错。我（我们都？）经常在内部使用单元测试来做到这一点。在使用我的单元测试来验证我没有破坏任何东西时，我也隐含地验证我的API合同没有改变。单元测试的自然用法似乎是以你正在讨论的方式部署它们。
答案 1 :(得分：5)
敏捷方法论说：测试是规范，所以这是一个非常好的主意。
答案 2 :(得分：5)
我完全希望能为此受到抨击，但我不明白一组单元测试如何证明客户关心的事情，即应用程序是否满足他的业务需求。
这是一个例子：我刚刚完成转换大量代码以解决我们犯下的一个大错误。这是一个经典的过度工程案例，这些变化触及了十几个窗口形式和大约几个类。
我花了几天时间，它现在变得更加简单，我们免费获得了一些功能，我们丢失了大量的代码，这些代码完成了我们现在知道的从未真正需要的东西。
这些形式中的每一种形式都完美无缺。公共方法确实完成了他们需要做的事情，并且基础数据访问也很好。
所以任何单元测试都会过去。
除了遗憾之外，他们做错了 - 我们没有意识到这一点。就好像我们已经构建了一个原型并且只是在尝试使用它之后，意识到它不对。
所以现在我们有一个更精简，更精简，更健康的应用程序。
但是那些错误的东西在单元测试永远无法揭示它们的水平上是错误的，所以我只是不理解如何通过安装运行一组单元测试做任何事情，除了给出一种虚假的安全感
也许我不理解某些东西，但在我看来，除非函数所提供的东西与所提供的测试处于同一级别，否则它们什么都不会证明。
答案 3 :(得分：1)
这实际上是一个非常好的主意，并且作为API用户非常愉快。
这种技术实际上也可以反过来使用：当您使用“遗留”API时，您可以使用单元测试来记录您认为API的行为方式，并验证它实际上是否按计划行事。
答案 4 :(得分：1)
如果您对使用代码提供一组规范感兴趣，也许您应该研究一些行为驱动的开发工具（nbehave，jbehave，rspec等）。这些框架支持在给定/ when / then语法中描述您的测试并输出使用自然语言的格式化结果。有关.NET的BDD工具的示例，请参阅nbehave。您可以找到BDD here
的出色描述另一种选择可能是您使用验收测试框架（例如fit或fitnesse（或仅限java concordion）编写测试，并使用代码提供这些验收测试。 fit / fitnesse和concordion都允许在纯HTML或甚至Word文档中指定测试。
任何一种方法（BDD或验收测试框架）的好处是用户看到的结果更易于人类阅读和理解。
答案 5 :(得分：1)
如果您要发布代码库，这听起来很棒。
如果您发布的是一个普通的软件产品，您的用户只能通过 GUI 进行交互，那么您的单元测试可能无法在相同的抽象级别下工作，也可能不是最有用的工具。评估产品的行为。一个非常好的用户手册（是的，这是可能的）可能更好。
答案 6 :(得分：0)
测试将检查要求。
要求定义功能
=＆GT;测试将检查功能。
问题是，只能检查单元测试可以涵盖的功能。集成或整个系统测试不起作用。
否则，这是TDD通过单元测试检查功能的主要方法。
答案 7 :(得分：0)
Meszaros将此“测试作为文档”