如何让人们找回对单元测试缺失的爱.docxVIP

上海市打浦路 1 号金玉兰广场西楼 902 室Rm. 上海市打浦路 1 号金玉兰广场西楼 902 室 Rm. 902, Golden Magnolia Plaza, W. 1 Dapu Road, Huangpu District 200023 Shanghai, P.R. China 如何让人们找回对单元测试缺失的爱 让我们面对现实吧。没有人真正喜欢做单元测试。许多人曾经在会议上向我描述他们是多么的厌恶单元测试。确实有一些人很擅长做单元测试，但对于大多数人来说单元测试就是无法避免的灾难，即便对于非常聪明的人来说也是如此。今天我要讲一些我们不喜欢单元测试的原因，以及如何通过自动化软件克服这些障碍。 那么，为什么要进行单元测试呢? 大多数开发团队都会承认，尽管他们不喜欢，但是单元测试实际上是有价值的。它帮助开发人员真正理解他们正在开发的代码，并为持续测试金字塔提供坚实的基础，正如右图所示。这反过来又能加速团队的敏捷开发，同时减少了缺陷的风险，从而使产品顺利进入了持续交付管道的后期阶段。 进一步来说，创建单元测试的过程本身就是有益的，它帮助开发人员通过不同的视角来查看他们的代码，本质上是在进行补充的代码审查。 当你进行单元测试时，可以从外部的角度查看功能接口，并从相应的问题中获益，例如， 我的代码将如何运行？（带来接口的简化以及更低的代码维护成本）或者，如果我得到了无效的数据，会发生什么？（生成更健壮和可重用的代码）。 为什么单元测试被搁置？ 通常，开发团队只做很少的单元测试，或者完全跳过，这主要是由于 压力和时间，在有限的时间中交付越来越多的功能 创建有价值的单元测试的复杂性和耗时的特性。 开发人员指出，将单元测试作为开发的核心实践有以下限制： 很难理解、初始化以及隔离被测单元的依赖关系。 确定要验证什么，并定义适当的断言是非常耗时的，并且常常需要“猜测”。 涉及到大量的手工代码，通常比实现特定功能或优化代码所做的要多。 这并不有趣，开发人员不想让人感觉像一个测试人员，他们想要将时间用于交付 更多的功能。 为了解除这些限制，有一些现成的工具可以帮助我们进行单元测试。单元测试以及断言框架提供了标准化的执行方式（如 Junit），以便无缝地集成到持续集成中（例如 Jenkins, Bamboo, TeamCity）。IDE 有助于创建测试代码（如 Eclipse、IntelliJ）。Mock 框架将代码从其依赖中分离出来（例如，Mockito, PowerMock）。代码覆盖工具为代码的执行提供了可见性（例如，Emma, Cobertura, Clover）。调试器允许开发人员监视和单步调试。 不幸的是，所有这些工具都有局限性，开发人员仍然会发现许多痛苦点，比如： IDE 有助于为单元测试创建一个框架，但不提供“内容”。开发人员还需要添加大量代码来创建执行测试： 断言需要手动定义，并且必须执行测试，以确定断言的正确性 Mock 框架需要大量的手工编码来实例化和配置，还需要正确地使用这些框架的 知识。 覆盖率工具提供了对执行测试所覆盖代码的展示，但是它们没有提供测试运行时行为的观察。 调试器可以用于单独的测试，但不能作为监控整个测试运行的方式。 总之，在开始将业务逻辑添加到测试之前，单元测试的创建仍然需要大量的手工、耗时和常常让人麻木的工作。 我们通过单元测试助手解决这一切 为了帮助你解决这些痛点，我们使用自动化测试软件，Parasoft Jtest 的单元测试助手 （UTA）现在可以帮助你通过点击一次按钮来创建一个功能齐全的单元测试。 用 UTA（单元测试助手）创建的测试只是一般的 Junit 测试用例，所有常规的测试工作都是为你完成。UTA 设置测试框架，实例化对象，并为被测试的方法所使用的对象和方法调用配置环境。 这些单元测试可以作为你的标准持续集成工作流的一部分，就像你现有的测试一样。而且当通过 UTA 执行测试时，包括您现有的测试时，测试就会以一种提供分析的方式进行监控，而不仅仅是提供代码覆盖率数据。 通过分析运行中的测试，UTA 能够提供一系列的建议，其中很多都提供了快速的修复，可以帮助你在一次点击时完成修复，比如： 突出显示已更改的对象值，并建议对该对象做断言 识别方法调用，以便更好地隔离正在测试的代码 查找那些不做资源释放的测试，并创建一个潜在的不稳定的测试环境（例如，由 于使用了线程、外部文件、静态字段或系统属性）。 我们创建 UTA 是为了解决单元测试的痛点，因为作为一个专门从事软件开发测试工作的组织，我们知道单元测试是创建安全、稳定、可靠和高质量软件的关键一步。因此，我希望在未 来的会议和活动中与你进行交流，而不是抱怨有多讨厌单元测试，你也可以告诉我们使用 UTA 来进行单元测试的经历。 单元测试助手操作