敏捷软件开发ASD-05-单元测试方法和实践.pptVIP

单元测试的方法与实践 尹俊文 国防科学技术大学计算机学院 1 单元测试 Red – Green – Refactor Red Write a little test that doesn‘t work (and perhaps doesn‘t even compile at first). Green Make the test work quickly (committing whatever sins necessary) Refactor Eliminate all of the duplication created in merely getting the test to work, improve the design. 为什么需要单元测试？ 测试是可执行的规范 首先考虑的是目标，然后才开绿实现。 可以通过观察测试理解程序的行为。测试比API描述包含的信息要多，它可以展示动态的信息（）怎样使用API。 开发可以是刚刚足够的！ 可以尽快地得到目标。 不需要开发不必要的代码。 没有代码是不经过测试的。 没有一个测试不来自于用户需求。 一旦得到了一个可工作的测试，可以知道这个测试现在可以运行，将来也一定可以！ 因为使用的测试是回归测试 测试给我们信心！ 测试赶走了恐惧！ 如何进行单元测试？ 首先不考虑对象 (或者设计，或者其它类似的东西), 一切从测试开始。 只有自动化测试失败了才编写新的代码 首先考虑你表，即所需要的功能 然后才考虑这个操作的接口 (从外部观察，即黑盒视图)。 经常运行测试——甚至是频繁运行 确定是否达到了目标 捕捉慢慢爬回来的bugs 走一小步 (编码和重构的时候) 只要这一步让你感到舒服就可以了 如果感觉不过瘾，步子再稍微走大一点 如果前进的速度没有达到你的期望，步子再稍微小一点 TDD的单元测试工具 自动化单元测试的框架 如，Junit 集成的开发环境 支持测试的编写，甚至可以自动完成和生成代码 支持测试的执行 支持重构 如，Eclipse Build环境 在build过程中可以自动执行测试 支持计算代码的覆盖率 支持生成测试报告 如，Maven 2 单元测试模式 单元测试模式 断言模式(Assertion patterns) 支架模式(Fixture patterns) 测试模式(Test patterns) 遗留代码的测试驱动开发 2.1 断言模式 断言模式 断言是测试的根本所在 Resulting State Assertion Guard Assertion Delta Assertion Custom Assertion Interaction Assertion Resulting State Assertion 检查被测试对象的内部状态在完成一个操作之后是否符合期望 Guard Assertion 检查被测试对象在执行一个操作之前的状态是否符合假设 Delta Assertion 如果被测对象不能在测试用例中受到完全的控制，结果状态模式和守卫模式不适用 Delta Assertion测试被测对象执行一个操作前后的状态差异 Custom Assertion 如果验证期望的测试代码的长度超出调用被测对象的代码长度时，需要将抽取一个客户断言方法来封装复杂的验证逻辑。 Interaction Assertion public class TestExpectedInteractions { private ListCustomer delivered; @Before public void setup() { delivered = new ArrayListCustomer(); } private class MockCustomer extends Customer { @Override public void onPaperDelivery(DailyPaper paper) { delivered.add(this); } } @Test public void paperBoyShouldDeliverPapers() throws Exception { Customer david = new MockCustomer(); Customer esther = new MockCustomer(); PaperBoy paperboy = new PaperBoy(); paperboy.addToRoute(david); paperboy.addToRoute(esther); paperboy.deliver(new DailyPaper()); assertTrue(delivered.contains(david); assertTrue(deliver