使用单元测试作为"功能合同"

单元测试通常与软件版本一起部署以验证安装 - 即安装,运行测试,如果它们通过则安装是好的.

我即将开始一个涉及向客户提供原型软件库发布的项目.单元测试将作为每个版本的一部分提供,除了使用测试来验证安装之外,我还计划使用测试API的单元测试作为如何使用发布的"合同".如果用户使用该版本的方式与单元测试的使用方式类似,那么很好.如果他们以其他方式使用它,那么所有的赌注都会被取消.

以前有人试过这个吗？是否这是一个好/坏主意的任何想法？

编辑:为了突出ChrisA和Dan在下面的回复中提出的一个好点,"测试API的单元测试"更好地称为集成测试,他们的目的是运用API和软件来演示软件的功能.客户的观点.

听起来对我来说是一个好主意.我(我们都？)经常在内部使用单元测试来做到这一点.在使用我的单元测试来验证我没有破坏任何东西时,我也隐含地验证我的API合同没有改变.单元测试的自然用法似乎是以你所谈论的方式部署它们.

敏捷方法论说:测试是规范,所以这是一个非常好的主意.

我完全希望能为此受到抨击,但我不明白一组单元测试如何证明客户关心的事情,即应用程序是否满足他的业务需求.

这是一个例子:我刚刚完成转换一大块代码来修复我们犯下的一个大错误.这是一个经典的过度工程案例,这些变化触及了十几种窗体和几乎一样的类.

这花了我几天,它现在变得更简单了,我们免费获得了一些功能,我们丢失了大量代码,这些代码完成了我们现在知道的从未真正需要的东西.

这些形式中的每一种形式都完美地运作.公共方法完全按照他们需要做的,并且基础数据访问就好了.

所以任何单元测试都会通过.

可悲的是,他们做错了 - 我们没有意识到,除了回想起来.就好像我们已经构建了一个原型,并且只有在尝试使用它之后才意识到这是不对的.

所以现在我们有一个更精简,更精简,更健康的应用程序.

但是那些错误的东西在单元测试永远无法揭示它们的水平上是错误的,所以我只是不理解如何通过安装运行一组单元测试除了给出一种虚假的安全感之外做什么.

也许我不理解的东西,但在我看来,除非是附带的事情功能在同级别提供的测试中,他们证明什么.