单元测试Unit Testing



Unit Test - Definition

单体测试定义

A unit test is an automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work.

单体测试ishi代码的自动化测试部分，它调用系统内的工作单元，然后验证关于工作单元行为的单个假设。

A unit of work is a single logical functional use case in the system that can be invoked by some public interface (in most cases). A unit of work can span a single method, a whole class or multiple classes working together to achieve one single logical purpose that can be verified.

工作单元是系统的单一逻辑功能用例，在多数情况下由一些公共接口调用。工作单元可以是一个单独的方法，整个类或者多各类共同作用达成单独的逻辑目的并且是可以被验证的。

http://artofunittesting.com/definition-of-a-unit-test/

http://martinfowler.com/eaaCatalog/unitOfWork.html

Unit of Work: Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.

工作单元维护了受业务事务影响的对象列表并且

Unit Test - Good unit test

好的单元测试

 A good unit test is:

一个好的单元测试应该是 

• Able to be fully automated
• 可以完全自动化的 
• Has full control over all the pieces running (Use mocks or stubs to achieve this isolation when needed) 
• 完全控制并覆盖所有运行的代码碎片(需要时使用mocks或者stubs实现隔离)
• Can be run in any order if part of many other tests 
• 与其它测试一起可以按任意次序运行
• Runs in memory (no DB or File access, for example) 
• 在内存中运行 (例如没有数据库或文件访问)
• Consistently returns the same result (You always run the same test, so no random numbers, for example. save those for integration or range tests) 
• 持续返回相同的结果(你一直运行相同的测试，没有随机数，例如保存那些的集成或范围测试)
• Runs fast 
• 运行很快
• Tests a single logical concept in the system 
• 在系统中测试一个单独的逻辑概念
• Readable 
• 具有可读性
• Maintainable 
• 具有可维护性
• Trustworthy (when you see its result, you don’t need to debug the code just to be sure)
• 值得信赖(当你看到结果，不需要再去调试代码来保证正确性)

I consider any test that doesn’t live up to all these as an integration test and put it in its own “integration tests” project.

我认为任何测试,不辜负所有这些作为一个集成测试,把它放进自己的“集成测试”项目。

Agile Unit Testing

敏捷单元测试

Unit tests are snippets of test code developers write to prove to themselves that what they are developing actually works. Think of them as codified requirements.

It should be a exploratory testing.

单元测试是测试代码的片段，开发人员编写单元测试保证他们开发的软件能正确的运行。将他们想象为编码的需求，应该是探索式的测试。

Agile Test Driven Development

敏捷测试驱动开发

Test Driven Development is about writing the test first before adding new functionality to the system. This seems backwards as first, but doing this:

测试驱动开发是在添加新的功能到系统时先编写测试用例。这看起来似乎本末倒置，但这样做：

• Defines success up front.
• 预先定义了成功的目标。
• Helps break our design down into little pieces, and
• 帮助我们将设计分成小块
• Leaves us with a nice suite of unit tests proving our stuff works.
• 留下一套单元测试保证我们开发的代码能验证正确性

Agile developers work in this circle of life when adding new code. Write the test first. Make it pass. Then refactor.

敏捷开发人员在这个生命周期内工作并添加新代码。编写测试然后让他们通过，最后重构。

Benefits of Test-Driven Development

测试驱动开发的好处

• The suite of unit tests provides constant feedback that each component is still working.
• 成套的单元测试持续的证明每个组件仍在正常工作
• The unit tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does.
• 单独测试扮演文档的角色不会过时，与分开的文档不同是可以频繁更新的
• When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test.
• 当测试通过并且生产代码通过重构消除重复，代码明确的已经完成，开发人员可以转移到下一个新的测试
• Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it.
• 测试驱动开发推动关键的分析和设计因为开发人员不能直接创建生产代码而不了解什么是最希望的结果应该的样子和如何测试它。
• The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time.
• 软件往往被更好的设计，松散耦合且易于维护，因为开发人员乐于为设计做决定并且在任何时候进行重构
• The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified.
• 测试组作为缺陷回归的安全网；如果发现一个缺陷，开发人员应该创建测试重新缺陷并且修改生产代码消灭缺陷这样所有测试通过。在每个成功运行的测试后，所有以前的缺陷修复都被验证。
• Reduced debugging time!
• 减少的调试时间。

Characteristics of a Good Unit Test

一个好的单元测试的特点

A good unit test has the following characteristics.

一个好的单元测试有如下特点

• Runs fast, runs fast, runs fast. If the tests are slow, they will not be run often.
• 运行速度快，如果运行速度慢就不能经常运行。
• Separates or simulates environmental dependencies such as databases, file systems, networks, queues, and so on. Tests that exercise these will not run fast, and a failure does not give meaningful feedback about what the problem actually is.
• 分离或者模拟环境依赖如数据库、文件系统、网络、队列等等。关于这些的测试都不会快速运行，失败也不会有实质性的反馈。
• Is very limited in scope. If the test fails, it's obvious where to look for the problem. Use few Assert calls so that the offending code is obvious. It's important to only test one thing in a single test.
• 非常有限的范围。如果测试失败显而易见可以定位到问题。使用少量的断言调用这样的代码是显而易见的。重要的是一个测试只测试一件事。
• Runs and passes in isolation. If the tests require special environmental setup or fail unexpectedly, then they are not good unit tests. Change them for simplicity and reliability. Tests should run and pass on any machine. The "works on my box" excuse doesn't work.
• 隔离运行和通过测试。如果测试需要特殊的环境设置或者总是非预期地失败。那就不是很好的测试。改变他们让他们更简单和可信赖。测试应该能在任何机器上运行并通过。在我这里是好用的并不代表全部。
• Often uses stubs and mock objects. If the code being tested typically calls out to a database or file system, these dependencies must be simulated, or mocked. These dependencies will ordinarily be abstracted away by using interfaces.
• 经常使用stubs和mock对象。如果要测试的代码经常调用数据库或文件系统，那些以来应该被模拟或mocked。这些依赖通常可以通过使用接口抽象。
• Clearly reveals its intention. Another developer can look at the test and understand what is expected of the production code.
• 能清楚的揭示意图。另一个开发人员可以通过阅读测试理解生产代码所要达到的功能。