我正在使用 NUnit 进行 TDD。我以行为风格命名我的 NUnit 测试(比如给定的,何时,然后)。但是,我现在将 MSpec 用于所有单元测试。我仍然首先编写测试,使用模拟等......所以,它们仍然是单元测试。但是,我认为不需要 NUnit。
我很紧张要放弃我在学习 NUnit 上所付出的所有努力。考虑到 BDD 是正确的 TDD,我是否应该完全放弃 TDD/NUnit?
我正在使用 NUnit 进行 TDD。我以行为风格命名我的 NUnit 测试(比如给定的,何时,然后)。但是,我现在将 MSpec 用于所有单元测试。我仍然首先编写测试,使用模拟等......所以,它们仍然是单元测试。但是,我认为不需要 NUnit。
我很紧张要放弃我在学习 NUnit 上所付出的所有努力。考虑到 BDD 是正确的 TDD,我是否应该完全放弃 TDD/NUnit?
既然您已经接受了 BDD,那么您将遵循“由外而内”的开发方法。
可以在programmers.stackexchange.com上找到对这种开发技术的简洁定义。我引用:
“Outside-In(伦敦学校,自上而下或 Martin Fowler 称之为“mockist TDD”):您预先了解交互和协作者(尤其是顶层的那些)并从那里开始(顶层),嘲笑必要的依赖关系. 对于每一个完成的组件,你移动到之前模拟的协作者那里并再次从 TDD 开始,创建实际的实现(即使使用了,由于抽象,以前不需要)。请注意,由外向内的方法与 YAGNI 原则相得益彰。”
使用 BDD 时,您以自上而下的方式开发并模拟依赖项以满足您的测试。一旦您的 BDD 测试通过,您就可以恢复使用 TDD来实现您在 BDD 测试期间遇到的依赖项的具体版本(使用“由内而外”的方法)。
因此,您的 TDD 和 BDD 测试都很有价值,因为它们测试代码的不同方面,即 BDD 测试确保针对系统中的所有层测试用户的交互,而 TDD 测试详细涵盖各个组件隔离(通过模拟)。
所以不要放弃你的 NUnit 测试!
为了结束我的回答,你说:
BDD 是正确的 TDD
正如我上面所解释的,BDD 和 TDD 之间的主要区别在于它们所涵盖的代码范围。Dan North 在这里有一篇很好的文章。
NUnit 和 MSpec 基本上是测试框架。它们都可以用于编写单元、集成或验收测试。您在层、行为或任何您的定义的正确交叉点实施测试。两个框架都支持 BDD 样式和命名。MSpec 通过自定义委托预先完成。NUnit 使它更具挑战性(您必须摆弄构造函数以及设置和测试方法)。
您仍然首先编写测试 (TDD),但现在您使用的是直接支持上下文/规范语法和行为测试 (BDD) 与对象结构测试的测试框架。
问题不在于 TDD 与 BDD、Arrange-Act-Assert 语法与上下文/规范语法或测试框架中的任何其他结构差异(每个上下文一个设置,每个规范一个断言等) ,但你的技能与特定的框架!
我说,拥抱你的新知识!你喜欢mspec吗?您是否可能让您的同事改用 mspec?你会完全忘记你的 NUnit 技能(API 或命令行运行器)吗?
如果您继承了一些旧项目或有喜欢 NUnit 的团队成员,这两个框架可以在您的解决方案和构建脚本中并存,几乎没有麻烦。有许多不同的方式来编写测试和报告结果并不是很好。
根据我的经验,在某些情况下 NUnit 仍然是一个不错的选择。例如,mspec 目前不支持示例,而 NUnit 有 TestCase 和 TestCaseSource。这些在单元测试场景中很有用,因此可能仍然需要使用 xUnit 样式工具。无需“忘记”任何东西,我认为了解工具带中的所有工具并为手头的任务选择正确的工具是件好事。