unit-testing - 单元测试/TDD 的有用设计模式?

标签 unit-testing design-patterns testing tdd

阅读this question帮助我解决了我在单元测试、TDD 等方面一直遇到的一些问题。

自从接触到 TDD 开发方法后,我就知道这是一条正确的道路。阅读各种教程帮助我了解了如何开始,但它们总是非常简单 - 并不是真正可以应用于事件项目的东西。我管理的最好的方法是围绕我的代码的一小部分编写测试——比如库,主应用程序使用但没有以任何方式集成。虽然这很有用,但它相当于大约 5% 的代码库。关于如何进入下一步的内容很少,可以帮助我在主应用程序中进行一些测试。

诸如“Most code without unit tests is built with hard dependencies (i.e.'s new's all over the place) or static methods.”和“...it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class [...] and so on.”之类的评论让我意识到下一步是了解如何解耦代码以使其可测试。

我应该注意什么来帮助我做到这一点?是否有一组特定的设计模式需要我理解并开始实现,以便更轻松地进行测试?

最佳答案

Mike Clifton 在这里描述了 2004 年的 24 种测试模式。它是设计单元测试时有用的启发式方法。

http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns

通过/失败模式

这些模式是您保证良好代码的第一道防线(或攻击,取决于您的观点)。但是请注意,他们告诉您的有关代码的内容具有欺骗性。

  • 简单测试模式
  • 代码路径模式
  • 参数范围模式

  • 数据交易模式

    数据事务模式是拥抱数据持久性和通信问题的开始。在“模拟模式”中讨论了有关此主题的更多信息。此外,这些模式有意省略了压力测试,例如在服务器上加载。这将在“压力测试模式”下讨论。
  • 简单数据 I/O 模式
  • 约束数据模式
  • 回滚模式

  • 馆藏管理模式

    许多应用程序所做的是管理信息集合。尽管有多种集合可供程序员使用,但验证(并记录)代码是否使用了正确的集合很重要。这会影响排序和约束。
  • 集合顺序模式
  • 枚举模式
  • 集合约束模式
  • 集合索引模式

  • 性能模式

    单元测试不应该只关注功能,还应该关注形式。被测代码执行其功能的效率如何?多快?它使用多少内存?它是否有效地权衡数据插入以进行数据检索?它是否正确释放资源?这些都是在单元测试范围内的事情。通过在单元测试中包含性能模式,实现者有一个要达到的目标,从而产生更好的代码、更好的应用程序和更快乐的客户。
  • 性能测试模式

  • 工艺模式

    单元测试旨在测试单元……应用程序的基本功能。可以争辩说,测试过程应该归入验收测试程序,但是我不认同这个论点。进程只是一种不同类型的单元。使用单元测试员测试流程提供与其他单元测试相同的优势——它记录了流程的工作方式,单元测试员还可以通过无序测试流程来帮助实现者,快速识别潜在的用户界面问题好。术语“流程”还包括状态转换和业务规则,两者都必须经过验证。
  • 进程序列模式
  • 进程状态模式
  • 流程规则模式

  • 模拟图案

    数据交易很难测试,因为它们通常需要预设配置、开放连接和/或在线设备(仅举几例)。模拟对象可以通过模拟与代码进行交易的数据库、Web 服务、用户事件、连接和/或硬件来解决问题。 Mock 对象还能够创建在现实世界中很难重现的故障条件——连接有损、服务器速度慢、网络集线器故障等。
  • 模拟对象模式
  • 服务模拟模式
  • 误码模拟模式
  • 组件仿真模​​式

  • 多线程模式

    单元测试多线程应用程序可能是最困难的事情之一,因为您必须设置一个条件,该条件本质上是异步的,因此是不确定的。这个话题本身可能是一篇重要的文章,所以我在这里只提供一个非常通用的模式。此外,要正确执行许多线程测试,单元测试器应用程序本身必须将测试作为单独的线程执行,以便在一个线程最终处于等待状态时不会禁用单元测试器
  • 信号模式
  • 死锁解决模式

  • 压力测试模式

    大多数应用程序都在理想的环境中进行了测试——程序员正在使用网络流量很小的快速机器,使用小数据集。现实世界是非常不同的。在某些事情完全中断之前,应用程序可能会降级并响应不佳或对用户出现错误。验证代码在压力下的性能的单元测试应该与理想环境中的单元测试相同(如果不是更多)。
  • 批量数据压力测试模式
  • 资源压力测试模式
  • 加载测试模式

  • 表示层模式

    单元测试最具挑战性的方面之一是验证信息是否在表示层本身传递给用户,以及应用程序的内部工作是否正确设置了表示层状态。通常,表示层与业务对象、数据对象和控制逻辑纠缠在一起。如果您计划对表示层进行单元测试,您必须意识到明确的关注点分离是强制性的。部分解决方案涉及开发适当的模型- View - Controller (MVC) 架构。 MVC 体系结构提供了一种在使用表示层时开发良好设计实践的方法。但是,它很容易被滥用。需要一定程度的纪律来确保您实际上正确地实现了 MVC 架构,而不仅仅是在文字上。
  • View 状态测试模式
  • 模型状态测试模式
  • 关于unit-testing - 单元测试/TDD 的有用设计模式?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/3840125/

    相关文章:

    php - 如何在 PHP 中实现 MVC

    c++ - 设计模式中对象中过程(方法和操作)的状态

    python测试框架

    delphi - 如何在delphi单元测试中使用可视化组件?

    c# - 单元测试是否捕获到异常

    unit-testing - 如何测试setter和getter?

    java - 设计模式(命令模式),以避免出现多个if条件

    java - 如何正确使用 DoThrow()

    testing - 集成测试的硬编码与软编码预期值

    reactjs - 如何使用获取 API 请求测试 Action 创建者