单元测试在一个完整的软件开发流程中是必不可少的、非常重要的一个环节。通常写单元测试并不难，但有的时候，有的代码和功能难以测试，导致写起测试来困难重重。因此，写出良好的可测试的（testable）代码是非常重要的。接下来，我们简要地讨论一下什么样的代码是难以测试的，我们应该如何避免写出难以测试的代码，以及要写出可测试性强的代码的一些最佳实践。
通常一个单元测试主要有三个行为：
这三个行为分别被称为Arrange,ActandAssert。以java为例，一般测试代码如下：
@TestpublicvoidisPalindrome(){//初始化：初始化需要被测试的模块，这里就是一个对象。//也可能没有初始化模块，例如测试一个静态方法。PalindromeDetectordetector=newPalindromeDetector();//调用方法：记录返回值，以便后续验证。//如果方法无返回值，那么我们需要验证它在执行过程中是否对系统的其他部分造成了影响，或产生了副作用。booleanisPalindrome=detector.isPalindrome("kayak");//断言：验证返回结果是否和预期一致。Assert.assertTrue(isPalindrome);}
单元测试的目的是为了验证颗粒度最小的、独立单元的行为，例如一个方法，一个对象。通过单元测试，我们可以确保这个系统中的每个独立单元都正常工作。单元测试的范围仅仅在这个独立单元中，不依赖其他单元。而集成测试的目的是验证整个系统在真实环境下的功能行为，即将不同模块组合在一起进行测试。集成测试通常需要将项目启动起来，并且可能会依赖外部资源，例如数据库，网络，文件等。
1.代码简洁清晰
我们会针对一个单元写多个测试用例，因此我们希望用尽量简洁的代码覆盖到所有的测试用例。
2.可读性强
测试方法的名称应该直截了当地表明测试内容和意图，如果测试失败了，我们可以简单快速地定位问题。通过良好的单元测试，我们可以无需通过debug，打断点的方式来修复bug。
3.可靠性强
单元测试只在所测的单元中真的有bug才会不通过，不能依赖任何单元外的东西，例如全局变量、环境、配置文件或方法的执行顺序等。当这些东西发生变化时，不会影响测试的结果。
4.执行速度快
通常我们每一次打包都会运行单元测试，如果速度非常慢，影响效率，也会导致更多人在本地跳过测试。
5.只测试独立单元
单元测试和集成测试的目的不同，单元测试应该排除外部因素的影响。
1.方法和数据源紧耦合在了一起
2.违反了单一职责原则（SingleResponsibilityPrinciple）
3.方法的职责不清晰
方法签名StringgetTimeOfDay()对方法职责的描述不清晰，用户如果不进入这个api查看源码，很难了解这个api的功能。
4.难以预测和维护
要解决这个问题，通常可以使用依赖注入（控制反转，IoC），控制反转是一种重要的设计模式，对于单元测试来说尤其有效。实际工程中，大多数应用都是由多个类通过彼此的合作来实现业务逻辑的，这使得每个对象都需要获得与其合作的对象（也就是他所依赖的对象）的引用，如果这个获取过程要靠自身实现，那会导致代码高度耦合并且难以测试。那如何反转呢？即把控制权从业务对象手中转交到用户，平台或者框架中。
@TestpublicvoidtestActuateLights(){Calendartime=GregorianCalendar.getInstance();time.set(2018,10,1,06,00,00);SmartHomeControllercontroller=newSmartHomeController(time);controller.actuateLights(true);Assert.assertEquals(time,controller.getLastMotionTime());}到这里，已经可以方便地对其做单元测试了，你认为这段代码已经具有良好的可测试性了吗？
我们仔细看这段开灯关灯的代码：
if(motionDetected&&("Evening".equals(timeOfDay)||"Night".equals(timeOfDay))){//晚上触摸台灯，开灯！BackyardLightSwitcher.Instance.TurnOn();}elseif(getIntervalMinutes(lastMotionTime,nowTime)>1||("Morning".equals(timeOfDay)||"Noon".equals(timeOfDay))){//超过一分钟没有触摸，或者白天，关灯！BackyardLightSwitcher.Instance.TurnOff();}这里通过控制BackyardLightSwitcher这个单例来控制台灯，这是一个全局的变量，意味着每次运行这个单元测试，可能会修改系统中变量的值。换句话说，这个测试产生了副作用。如果有其他的单元测试也依赖了BackyardLightSwitcher的值，那么测试的结果就变得不可控了。因此这个方法依旧不具有良好的可测试性。
java8中引入了函数式和一等公民的概念。我们熟悉的对象是数据的抽象，而函数是某种行为的抽象。
@TestpublicvoidtestActuateLights(){Calendartime=GregorianCalendar.getInstance();time.set(2018,10,1,06,00,00);MockLightmockLight=newMockLight();SmartHomeControllercontroller=newSmartHomeController(time);controller.actuateLights(true,mockLight::turnOn,mockLight::turnOff);Assert.assertTrue(mockLight.turnedOn);}//用于测试publicclassMockLight{booleanturnedOn;voidturnOn(){turnedOn=true;}voidturnOff(){turnedOn=false;}}
现在，我们真正拥有了一个可测试的方法，它非常稳定、可靠，不必担心对系统产生副作用，同时我们也具有了清晰易懂、可读性强、可重用的api。
在函数式编程中，有一个概念叫纯函数，纯函数的主要特点是：
像这样的函数一般具有非常好的可测试性，对它做单元测试方便、且不会出问题，我们需要做的就只是传参数进去，然后检查返回结果。对于不纯的函数，例如某个函数Foo()，它依赖了一个有副作用的函数Bar()，那么Foo()也变成了一个有副作用的函数，最终，副作用可能会遍布整个系统。