我对单元测试的理解
我对单元测试的理解 保证测试的代码符合编写时的预期 目前为止，我还没有系统的学习过测试领域的知识，但是测试对于研发岗来说是重要的。测试在我的日常工作中主要是起到程序逻辑校验的作用，作为研发来说，自己做的单元测试的目的主要在于程序逻辑，而不是业务逻辑。也就是说，单元测试能保证通过单元测试的代码一定是符合我的预期的，而我的预期本身是不是有问题没法通过单元测试校验，需要集成测试以及专业的测试团队进行测试。 单元测试帮助我快速复现bug 在实际生产过程中，我的单元测试足够多，覆盖面足够广，那么出了问题的时候就可以快速定位到出错代码的单元测试。这样修改代码，就可以针对单元测试来进行修改。当然，这里也会出现，bug出现了却没有制定的单元测试，这时就可以添加单元测试，在修复bug的同时丰富单元测试用例。我称之为基于单元测试的敏捷开发。 单元测试帮助代码重构 这有两方面，第一方面是有了单元测试，在代码重构时就能可以保证代码的输入和输出不会出问题，那就可以放心大胆的一步一步重构。第二方面，单元测试也能保证代码质量，因为越小的代码，耦合越低的代码越容易进行单元测试。有的一些代码在写单元测试的时候会发现根本无从下手，这就是很明显的代码坏味道。 单元测试帮助阅读和理解旧代码 我发现这一点很少有人提及，因为单元测试一般都是测试一些比较关键的代码，而且输入和输出都会明确列举出来。如果源代码里有单元测试，那么读单元测试就能很清晰的了解到这一块代码的作用是什么。而如果没有单元测试，又有一块代码的逻辑不是很清晰，那么也可以通过补充单元测试的方式来搞懂代码。说白了，单元测试就是可以将一块代码简化成输入->输出这种形式，更易于人脑解析。 研发的单元测试比重 很多人不想写单元测试，是觉得单元测试时间太长。其实单元测试的好处大家都知道，如果给予更多的开发周期，相信更多人会花时间在单元测试上。其实这里关键的问题不止单元测试值不值得做，还有单元测试耗费的时间到底长不长。单元测试一定值得做，上面提到的好处在整体上一定会减少开发时间。而单元测试耗费的时间到底长不长呢？这就要提到一个误区了，有不少人是把单元测试也当作代码来写，这并没有太多问题，但是单元测试是一种工具，那么使用这种工具就一定是越简单越快越好，直白点就是有轮子就用轮子，代码越简单越好。比如写java的单元测试，如果不引用单元测试框架，但确实折磨，引入了框架再加上一些mock工具就很更加简单，而如果再使用一些辅助语言比如groovy或者scala，单元测试就会变得十分简单，就是在程序编写时顺手的一个工作。 Spock单元测试推荐 我再尝试了一些单元测试框架和mock工具之后，目前在写java程序时稳定使用的是spock测试框架，这时一个基于groovy的单元测试框架，groovy和java代码可以无缝接入，所以我的代码一般都是主程序用java写，测试程序用groovy写。 简单的spock测试程序大概长这样： class PropertyCopierTest extends Specification { def "CopyBeanProperties"() { given: def sourceBean = new TestProperty("beanOne", 100) def destinationBean = new TestProperty() when: PropertyCopier.copyBeanProperties(TestProperty.class, sourceBean, destinationBean) then: destinationBean.with { name == "beanOne" id == 100 } } } spock的教程网上有很多，我就不累述了： Spock单元测试框架介绍以及在美团优选的实践 用Groovy更迅速地对Java代码进行单元测试 Introduction to Testing with Spock and Groovy 单元测试和Mock工具中的一些通用概念 mock mock就是直接通过类创建一个对象，这个对象的返回值是模拟出来的也就是程序调用到指定方法就返回你事先定义好的值。 比如用Mockito框架mock： //模拟PersonDao对象 mockDao = mock(PersonDao.class); when(mockDao.getPerson(1)).thenReturn(new Person(1, "Person1")); when(mockDao....