首先，这是一篇入门级的文章，高手可以无视。
在国内大部分的公司都不要求，或者难以要求，以至于工作了很多年的程序员都不知道如何去写一个正确的单元测试。当然，你会在网上看到很多文章告诉你如何使用 Junit，然后告诉你单元测试就是使用 Junit，真是无知又无耻，不仅写的人不知道什么是单元测试，还“毁人不倦”。实在忍受不了，便有了这篇文章。
老生常谈的好处
单元测试位于测试金字塔的最底层，越向上反馈的时间越长，实现的成本也越高。
测试金字塔
测试的好处不仅仅是在编码时可以快速验证我们的程序是否满足预期，更大的好处是未来修改另一个功能时，可以帮助我们快速回归之前的所有测试，以确定此修改的影响范围。比人工的效率更高而且更加可靠。
单元测试的要求
好处说完了，怎么样测试才算是单元测试呢？
●有明确的预期
●可重复运行
●没有副作用
时间
随机数
并发性
基础设置
持久化
网络
有【明确预期】和【可重复运行】都比较好理解，可【没有副作用】这要如何做到呢？我们的业务系统做的所以事情都是依赖数据和网络的。
这需要把代码做更合理的划分，软件的最大价值是实现业务逻辑，而不仅仅是将数据放入数据库，假设我们的服务运行在一个内存无限大，永远不宕机的环境上，我们是否还需要使用数据库，有点扯远了。
要把业务逻辑中外部依赖中解耦出来，使职责更加的清晰也更好的测试。说了这么多估计一半同学已经睡着了，后面介绍一些极其有用方法（工具），请往下看~
更有效的方法-测试替身（Test Double）
测试替身可以帮助我们与真实的数据库、网络等其他外部依赖有效的隔离开，从而只测试我们关心的逻辑部分。
Stub（桩）
代码中不包含逻辑，作为替身只返回固定数据，不做测试以外的任何事。我们以 Java 为例，看一下代码：
public class LogStub implement Logger { public String getLevel() { return 'DEBUG'; } } |
Fake（伪装者）
大多时候我们需要根据数据库中的数据进行判断，例如下面的代码：
public class UserService { private UserRepository userRepository; public UserService(UserRepository userRepository) { this.userRepository = userRepository; } public void register(User user) { User tempUser = userRepository.getUserByEmail(user.getEmail()); if (tempUser != null) { throw new Exception("已经存在相同的邮箱，请重新输入。"); } userRepository.save(user); // 发邮件... } } |
UserRepository 是对数据库的访问，然而我们并不需要真正的数据库，只需要对 UserRepository 制作一个基于内存的 Fake 对象即可，如下：
public class UserRepositoryFake extends UserRepository { private Map<String, User> usersMap = new HashMap<String, User>(); public UserRespositoryFake() { usersMap.put('111@111.com', new User(...)); usersMap.put('222@222.com', new User(...)); // ... } public void save(User user) { usersMap.put(user.getEmail(), user); } public user getUserByEmail(email) { return usersMap.get(email); } } |
Fake 是更加接近于生产行为的替身，但并不能用于生产环境。
Spy（间谍）
对于有返回值的方法我们可以使用 Stub 很容易测试，但对于没有返回值的方法，例如下面这段：
public class EmailSender { public void send(User user) { // 发邮件给用户... } } public class UserService { private EmailSender emailSender; public UserService(EmailSender emailSender) { this.emailSender = emailSender; } public void register(User user) { // 注册逻辑... emailSender.send(user); } } |
在用户注册之后需要给用户发邮件，虽然发邮件不是我们关注的点，但我们仍然关心是否被成功调用，邮件的 send() 没有返回值，此时需要放出小间谍来帮助我们来完成测试：
class EmailSenderSpy extends EmailSender { private Boolean called = false; public boolean getCalled() { return this.called; } @Override public void sender(User user) { this.called = true; } } // 测试部分 @Test public void should_called_send_email_to_user() { EmailSenderSpy spy = new EmailSenderSpy(); UserService userService = new UserService(spy); User user = new User(...); assertEquals(false, spy.getCalled()); userService.register(user); assertEquals(true, spy.getCalled()); } |
Mock
Mock 则是根据特定条件，返回特定的值，以验证代码的执行结果是否正确，典型的应用场景就是 Mock Server 。
这四种工具的分类界限比较模糊，我个人认为这样的分类并不合理，其他资料和框架的解释也不一致，但大神如此划分必定有其理由，读者不需要在此处过多纠结，在复杂的测试中可能一次就实现 Stub、 Fake、Spy 几种工具，只要知道实现方法，多多实践。
总结
花几分钟就可以写好一个单元测试，带来的回报却是巨大的。无论是后端还是前端都有相应的工具帮助我们轻松实现，做为 Java 程序员真的非常幸福，有 Junit 、Mockito 、PowerMock 、JMockit 这样一堆非常优秀的工具，前端也有很多优秀工具，就不一一列举，我在之前的几篇文章中也有单元测试的示例，欢迎有兴趣的同学翻看。
单元测试是一个软件保证质量的基础，也是作为一名优秀程序员的基本技能，后面会与大家在聊聊测试驱动开发（TDD），希望本文能给您带来收获。
上文内容不用于商业目的，如涉及知识产权问题，请权利人联系博为峰小编(021-64471599-8017)，我们将立即处理。
