让单元测试更简单

让单元测试更简单

阅读引导：

1、程序员的脸面，就是代码质量。

2、重视单元测试，提高交付的代码质量

3、为自己工作，为自己的系统工作，做自己的老板，形成正循环：打磨当前工作的核心关键能力——>高效能工作——>更多时间打磨自己的系统——>更高效能工作——>打磨下个层次工作的核心关键能力……

4、核心竞争力，是指你拥有的（独特的）知识经验组合，经过你思维逻辑的组织梳理，在实践中产生无可替代的价值。打造自己的TMS系统（T：专业技术；M：沟通管理、S：行业解决方案），利用复利效应，让系统为自己工作。

工作中有一个现象：

越是高手，越是重视单元测试；越是菜鸟，越不愿意写单元测试。

可能对于菜鸟来说，写完代码就已经非常筋疲力尽了，代码堆完之后，赶紧提交去集成测试……但是，最大的可能性，就是联调过程中经常出现问题，不停地回头修改，反而让整个联调测试进度更滞后。

于是，大家脸上笑嘻嘻，心里却不停吐槽：不靠谱、能力差、拖后腿……各种负面标签打在了菜鸟身上。

于是菜鸟越战战兢兢，更快的堆代码，更快的提交联测……恶性循环。

瞎忙！

高手喜欢单元测试的原因

与菜鸟把单元测试作为负担不同，高手非常喜欢单元测试，因为单元测试能带来无穷的好处。

首先，单元测试驱动开发者重新梳理完善代码逻辑。

我们平常开发的代码，如果说60%是在写正向逻辑，那么剩下的40%就是在处理各种异常情况，从而保证程序的健壮性。

很显然，在使用单元测试的时候，最基本的保证是正向主逻辑通过。

然后，在思考测试用例，思考测试边界的时候，其实就对相当于对自己的代码进行了一次审查。

交付出去的代码质量自然比没有经过测试的高很多。

这也是所谓的TDD测试驱动开发理念的一个要点。

其次，单元测试提升了修改功能的效率与正确性，提升了交付质量。

对于存量功能的修改，如果没有保留测试用例，每次都需要重新思考一遍逻辑。

而有了保留的单元测试用例，完全可以直接重新跑一遍，进行回归测试。

有测试用例保证质量，开发人员的心态，对于代码的把控程序，以及代码的交付质量完全不一样。

最后，单元测试很简单。

如果一个技术使用起来非常复杂，它一定不是好技术。

单元测试，除了菜鸟程序员改变观念以外，因为高手积累了一些工具，让测试变的简单。

下面以Spring框架使用JUnit单元测试框架测试，简单说明。

JUnit单元测试集成到Spring中

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration("classpath:applicationContext.xml")
public class BaseTest {
	@Autowired
	ApplicationContext context;

}

在开发自己的测试类时，集成上面的test基类，就可以只关注业务逻辑：

public class JmsProducerTest extends BaseTest {
	@Autowired
	private JmsProducer jmsProducer;

	@Test
	public void testSend() throws InterruptedException {
		jmsProducer.sendMessages();
		……
	}
}

另外，JUnit还有如下的特性，可以封装使用

Test Suite 测试组件

可以把多个测试类组合起来，统一管理。

setUpBeforeClass()，在类初始化之前做的事情，例如连接数据库，读取文件等……

setUp()，在每个测试方法执行前做的事情

以及销毁的方法

tearDownAfterClass()

tearDown()

在工作中，有一个绕不开的话题，那就是数据库。

因为我们开发的大部分服务，都是对数据库进行操作。

但是，我们又担心单元测试的数据，会对数据库中的数据造成“污染”。

实际上单元测试是自动回退的。除非在方法上面加上了@Rollback(false)

对自己的代码有追求

这只是一个简单的例子，在同一个项目组同一个系统，积累的越多，测试开发就会消耗的越少。

作为一个程序员，要对自己的代码质量有追求。

不断进步。

junit基础规范

Test类在test包下，要与java包中的被测试类，同样的路径；并且测试类的名字，是在被测试类后面加上Test

Test类中，每一个test方法，都是一个测试用例！

善用Test类中的的@setUp @tearDown等全局方法注解，可以在测试需要插入数据、测试完成删除数据的情况下使用。