对单元测试/ TDD有用的设计模式？ [英] Useful design patterns for unit testing/TDD?

问题描述

阅读此问题帮助我解决了单元测试，TDD等方面一直存在的一些问题

Reading this question has helped me solidify some of the problems I've always had with unit-testing, TDD, et al.

由于遇到了TDD开发方法，所以我知道这是正确的方法。阅读各种教程可以帮助我理解如何入门，但是它们一直都非常简单-并不是一个可以应用于活动项目的东西。我所管理的最好的方法是围绕我的代码的一小部分编写测试-例如库，这些代码由主应用使用，但没有以任何方式集成。尽管这很有用，但它约等于代码库的5％。

Since coming across the TDD approach to development I knew that it was the right path to follow. Reading various tutorials helped me understand how to make a start, but they have always been very simplistic - not really something that one can apply to an active project. The best I've managed is writing tests around small parts of my code - things like libraries, that are used by the main app but aren't integrated in any way. While this has been useful it equates to about 5% of the code-base. There's very little out there on how to go to the next step, to help me get some tests into the main app.

注释，例如 大多数不带单元测试的代码都是通过硬性依赖（即到处都是新的）或静态方法构建的。 和 ...在类之间具有高级别的耦合且难以配置的情况并不少见类中的对象等等。 使我意识到下一步是了解如何解耦代码以使其可测试。

Comments such as "Most code without unit tests is built with hard dependencies (i.e.'s new's all over the place) or static methods." and "...it's not rare to have a high level of coupling between classes, hard-to-configure objects inside your class [...] and so on." have made me realise that the next step is understanding how to de-couple code to make it testable.

我应该怎么看才能帮助我做到这一点？我是否需要理解并开始实施一组特定的设计模式，以简化测试？

What should I be looking at to help me do this? Is there a specific set of design patterns that I need to understand and start to implement which will allow easier testing?

推荐答案

Clifton描述了2004年以来的24种测试模式。在设计单元测试时，它是一种有用的启发。

Here Mike Clifton describes 24 test patterns from 2004. Its a useful heuristic when designing unit tests.

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

通过/失败模式

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

These patterns are your first line of defence (or attack, depending on your perspective) to guarantee good code. But be warned, they are deceptive in what they tell you about the code.

• 简单测试模式


• 代码路径模式


• 参数范围模式

数据交易模式

数据交易模式是拥抱数据持久性和通信问题的起点。在模拟模式下讨论了有关此主题的更多信息。同样，这些模式有意省略了压力测试，例如，服务器上的负载。这将在压力测试模式下进行讨论。

Data transaction patterns are a start at embracing the issues of data persistence and communication. More on this topic is discussed under "Simulation Patterns". Also, these patterns intentionally omit stress testing, for example, loading on the server. This will be discussed under "Stress-Test Patterns".

• 简单数据I / O模式


• 约束数据模式


• 回滚模式

集合管理模式

许多应用程序要做的是管理信息收集。尽管程序员可以使用各种各样的集合，但是重要的是验证（并记录）代码是否使用了正确的集合。这会影响排序和约束。

A lot of what applications do is manage collections of information. While there are a variety of collections available to the programmer, it is important to verify (and thus document) that the code is using the correct collection. This affects ordering and constraints.

• 收款顺序模式


• 枚举模式li>
  
• 集合约束模式


• 集合索引模式

性能模式

单元测试不仅应关注功能，还应关注形式。被测代码如何有效地执行其功能？多快？它使用多少内存？是否可以权衡数据插入以有效地进行数据检索？是否正确释放资源？这些都是单元测试的范围。通过在单元测试中包括性能模式，实现者可以实现一个目标，这将导致更好的代码，更好的应用程序和更满意的客户。

Unit testing should not just be concerned with function but also with form. How efficiently does the code under test perform its function? How fast? How much memory does it use? Does it trade off data insertion for data retrieval effectively? Does it free up resources correctly? These are all things that are under the purview of unit testing. By including performance patterns in the unit test, the implementer has a goal to reach, which results in better code, a better application, and a happier customer.

• 性能测试模式

过程模式

单元测试旨在测试单元……应用程序的基本功能。可以争辩说，测试过程应该归结为验收测试程序，但是我不赞成这种说法。流程只是一种不同类型的单元。使用单元测试器测试过程具有与其他单元测试相同的优势-它记录了该过程的工作方式，并且单元测试器还可以通过不按顺序测试该过程来帮助实现者，从而快速识别潜在的用户界面问题。好。 过程一词还包括状态转换和业务规则，这两个条件都必须经过验证。

Unit testing is intended to test, well, units...the basic functions of the application. It can be argued that testing processes should be relegated to the acceptance test procedures, however I don't buy into this argument. A process is just a different type of unit. Testing processes with a unit tester provide the same advantages as other unit testing--it documents the way the process is intended to work and the unit tester can aid the implementer by also testing the process out of sequence, rapidly identifying potential user interface issues as well. The term "process" also includes state transitions and business rules, both of which must be validated.

• 过程顺序模式


• 过程状态模式


• 过程规则模式

仿真模式

数据交易难以测试，因为它们通常需要预设配置，开放的连接和/或在线设备（仅举几例）。模拟对象可以通过模拟与代码进行交易的数据库，Web服务，用户事件，连接和/或硬件来抢救。模拟对象还具有创建在现实世界中很难重现的故障条件的能力-有损连接，服务器速度慢，网络集线器故障等。

Data transactions are difficult to test because they often require a preset configuration, an open connection, and/or an online device (to name a few). Mock objects can come to the rescue by simulating the database, web service, user event, connection, and/or hardware with which the code is transacting. Mock objects also have the ability to create failure conditions that are very difficult to reproduce in the real world--a lossy connection, a slow server, a failed network hub, etc.

• 模拟对象模式


• 服务模拟模式


• 误码模拟模式


• 组件模拟模式

• Mock-Object Pattern
• The Service-Simulation Pattern
• The Bit-Error-Simulation Pattern
• The Component-Simulation Pattern

多线程模式

对多线程应用程序进行单元测试可能是最困难的事情之一，因为您必须设置一个条件，即从本质上讲它是异步的，因此是不确定的。该主题本身可能是一篇主要文章，因此在这里我仅提供一个非常通用的模式。此外，为了正确执行许多线程测试，单元测试器应用程序本身必须将测试作为单独的线程执行，以便当一个线程最终处于等待状态时，不会禁用单元测试器。

Unit testing multithreaded applications is probably one of the most difficult things to do because you have to set up a condition that by its very nature is intended to be asynchronous and therefore non-deterministic. This topic is probably a major article in itself, so I will provide only a very generic pattern here. Furthermore, to perform many threading tests correctly, the unit tester application must itself execute tests as separate threads so that the unit tester isn't disabled when one thread ends up in a wait state

• 信号模式


• 死锁解决模式

压力测试模式

大多数应用程序都在理想的环境中进行了测试-程序员使用的是速度较快的计算机，网络流量很少，小数据集。现实世界是非常不同的。在某些事物完全崩溃之前，该应用程序可能会遭受性能下降，响应不佳或对用户造成错误。验证代码在压力下的性能的单元测试应该与理想环境中的单元测试具有相同的热情（如果不更多）。

Most applications are tested in ideal environments--the programmer is using a fast machine with little network traffic, using small datasets. The real world is very different. Before something completely breaks, the application may suffer degradation and respond poorly or with errors to the user. Unit tests that verify the code's performance under stress should be met with equal fervor (if not more) than unit tests in an ideal environment.

• 批量数据压力测试模式


• 资源压力测试模式


• 加载测试模式

演示层模式

单元测试最具挑战性的方面之一正在验证信息是否已在表示层本身直接到达用户，并且应用程序的内部工作正确设置了表示层状态。通常，表示层与业务对象，数据对象和控制逻辑纠缠在一起。如果您打算对表示层进行单元测试，则必须意识到必须将关注点明确分开。解决方案的一部分涉及开发适当的模型-视图-控制器（MVC）架构。当使用表示层时，MVC体系结构提供了一种开发良好设计实践的方法。但是，它很容易被滥用。需要一定的纪律以确保您实际上正确地实现了MVC架构，而不是仅凭文字就能实现。

One of the most challenging aspects of unit testing is verifying that information is getting to the user right at the presentation layer itself and that the internal workings of the application are correctly setting presentation layer state. Often, presentation layers are entangled with business objects, data objects, and control logic. If you're planning on unit testing the presentation layer, you have to realize that a clean separation of concerns is mandatory. Part of the solution involves developing an appropriate Model-View-Controller (MVC) architecture. The MVC architecture provides a means to develop good design practices when working with the presentation layer. However, it is easily abused. A certain amount of discipline is required to ensure that you are, in fact, implementing the MVC architecture correctly, rather than just in word alone.

• 视图状态测试模式


• 模型状态测试模式

这篇关于对单元测试/ TDD有用的设计模式？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！