使用Fit/FitNesse而不是xUnit风格的集成测试有什么意义?在我看来,它的语法非常奇怪且非常不清晰.
真的只是让产品所有者编写测试吗?他们不会!这对他们来说太复杂了.那么为什么有人会Fit/FitNesse?
更新因此它仅适用于业务规则测试吗?
重点是与非程序员合作,通常甚至是完全非技术人员,如业务应用程序的潜在客户,应该在什么应用程序上做,然后将其投入测试.虽然使测试工作对他们来说当然太复杂,但他们应该能够讨论例如Word中填写的样本数据表.最棒的是,与传统规范不同,这些文档与您的应用程序一起使用,因为自动化测试会强制您更新它们.
请参阅James Shore的" 适合和适合工作流程简介",如果需要,请单击其他文档的链接.
更新:取决于业务规则的含义?;-)有些人会非常狭隘地理解它(比如商业规则引擎等),其他人 - 非常广泛.
正如我所看到的,Fit是一种工具,它允许您在文档中写下具有丰富实际示例的业务(如域中)用例,最终用户或域专家(在某些域中)可以理解,验证和讨论.同时这些示例是机器可读的形式,因此它们可用于驱动自动化测试.您既不是完全自己编写文档,也不是要求它们执行.相反,它是一种精心设计和讨论的产物,反映了双方对应用程序将要做什么的日益增长的理解.随着进度的变化,示例变得更加丰富,并且更多的角点案例得到解
什么应用程序将做,而不是如何,重要.这是一种功能规范.因此它相当广泛,并不是真正按模块组织,而是使用场景.
从业务角度来看,示例中的测试将测试应用程序的外部行为.是的,您可以称之为业务规则.但让我们看看Diego Jancic的信用评分示例,只是稍微扭曲一下.如果适合文档的一部分是1)列出属性及其分数然后2)提供客户数据和检查结果,那么这是实际的业务规则:评分表(属性及其分数)或计算每个客户的分数的应用程序逻辑(根据得分表)?哪些经过测试?
Fit/FitNesse测试似乎更适合验收测试.其他测试(当您不关心与客户,用户,领域专家等的合作时,您只想自动化测试)可能更容易以更传统的方式编写和维护.xUnit非常适合单元测试和api测试.每个Web框架都应该有一些集成在其modify-build-test-deploy周期中的Web应用程序/服务测试工具,例如.django有它的小测试客户端.你有很多选择.
并且你总是可以编写自己的工具(或者最好调整一些现有工具)以更好地适合(双关语)在你感兴趣的特定领域进行一些测试.
一般的想法.通常(并不总是!!!)更好地编码您的测试,"业务规则"以及任何事物,在某种形式的明确定义的数据中,由一些简单的通用代码解释.然后以其他方式使用数据很容易:生成文档,迁移到新的测试框架,将应用程序移植到新的环境/编程语言,用于检查与某些外部规则或其他系统的一致性(只需使用您的想象力).从代码中提取这些信息要困难得多,例如.简单的硬编码单元测试或业务规则.
Fit将测试用例存储为数据.在非常具体的格式,因为它打算如何使用,但仍然.您的特定于域的测试可能使用不同的格式,如简单的CSV,JSON或YAML.