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

1、.如何让人们找回对单元测试缺失的爱让我们面对现实吧。没有人真正喜欢做单元测试。许多人曾经在会议上向我描述他们是多么的厌恶单元测试。确实有一些人很擅长做单元测试，但对于大多数人来说单元测试就是无法避免的灾难，即便对于非常聪明的人来说也是如此。今天我要讲一些我们不喜欢单元测试的原因，以及如何通过自动化软件克服这些障碍。那么，为什么要进行单元测试呢"大多数开发团队都会承认，尽管他们不喜欢，但是单元测试实际上是有价值的。它帮助开发人员真正理解他们正在开发的代码，并为持续测试金字塔提供坚实的基础，正如右图所示。这反过来又能加速团队的敏捷开发，同时减少了缺陷的风险，从而使产品顺利进入了持续交付管

2、道的后期阶段。进一步来说，创建单元测试的过程本身就是有益的，它帮助开发人员通过不同的视角来查看他们的代码，本质上是在进行补充的代码审查。当你进行单元测试时，可以从外部的角度查看功能接口，并从相应的问题中获益，例如，我的代码将如何运行.（带来接口的简化以及更低的代码维护成本）或者，如果我得到了无效的数据，会发生什么.（生成更健壮和可重用的代码）。为什么单元测试被搁置.通常，开发团队只做很少的单元测试，或者完全跳过，这主要是由于(1)压力和时间，在有限的时间中交付越来越多的功能(2)创建有价值的单元测试的复杂性和耗时的特性。开发人员指出，将单元测试作为开发的核心实践有以下限制：· 很难理

3、解、初始化以及隔离被测单元的依赖关系。· 确定要验证什么，并定义适当的断言是非常耗时的，并且常常需要“猜测”。· 涉及到大量的手工代码，通常比实现特定功能或优化代码所做的要多。· 这并不有趣，开发人员不想让人感觉像一个测试人员，他们想要将时间用于交付更多的功能。为了解除这些限制，有一些现成的工具可以帮助我们进行单元测试。单元测试以及断言框架提供了标准化的执行方式（如Junit），以便无缝地集成到持续集成中（例如Jenkins, Bamboo, TeamCity）。IDE有助于创建测试代码（如Eclipse、IntelliJ）。Mock框架将代码从其依赖中分离出来（

4、例如，Mockito, PowerMock）。代码覆盖工具为代码的执行提供了可见性（例如，Emma, Cobertura, Clover）。调试器允许开发人员监视和单步调试。不幸的是，所有这些工具都有局限性，开发人员仍然会发现许多痛苦点，比如：· IDE有助于为单元测试创建一个框架，但不提供“内容”。开发人员还需要添加大量代码来创建执行测试：· 断言需要手动定义，并且必须执行测试，以确定断言的正确性· Mock框架需要大量的手工编码来实例化和配置，还需要正确地使用这些框架的知识。· 覆盖率工具提供了对执行测试所覆盖代码的展示，但是它们没有提供测试运行时行

5、为的观察。· 调试器可以用于单独的测试，但不能作为监控整个测试运行的方式。总之，在开始将业务逻辑添加到测试之前，单元测试的创建仍然需要大量的手工、耗时和常常让人麻木的工作。我们通过单元测试助手解决这一切为了帮助你解决这些痛点，我们使用自动化测试软件，Parasoft Jtest的单元测试助手（UTA）现在可以帮助你通过点击一次按钮来创建一个功能齐全的单元测试。用UTA（单元测试助手）创建的测试只是一般的Junit测试用例，所有常规的测试工作都是为你完成。UTA设置测试框架，实例化对象，并为被测试的方法所使用的对象和方法调用配置环境。这些单元测试可以作为你的标准持续集成工作流的一部分，

6、就像你现有的测试一样。而且当通过UTA执行测试时，包括您现有的测试时，测试就会以一种提供分析的方式进行监控，而不仅仅是提供代码覆盖率数据。通过分析运行中的测试，UTA能够提供一系列的建议，其中很多都提供了快速的修复，可以帮助你在一次点击时完成修复，比如：· 突出显示已更改的对象值，并建议对该对象做断言· 识别方法调用，以便更好地隔离正在测试的代码· 查找那些不做资源释放的测试，并创建一个潜在的不稳定的测试环境（例如，由于使用了线程、外部文件、静态字段或系统属性）。我们创建UTA是为了解决单元测试的痛点，因为作为一个专门从事软件开发测试工作的组织，我们知道单元测试是创建安全、稳定、可靠和高质量软件的关键一步。因此，我希望