kafka-junit：JUnit rule for spinning up a Kafka broker

kafka-junit：This library wraps Kafka's embedded test cluster, allowing you to more easily create and run integration tests using JUnit against a "real" kafka server running within the context of your tests.

spring-kafka-test：封装了Kafka-test提供了注解式的一键开启Kafka Server的功能

 

test-tools不支持kafka的单元测试，若是用户有需要，可以直接使用spring-kafka-test，也可以使用kafka-junit（kafka-junit的使用要注意kafka-client的版本）

 

单元测试与覆盖率

 

覆盖率或测试覆盖率是用来衡量单元测试对功能代码的测试情况，通过统计单元测试中对功能代码中行、分支、类等模拟场景数量，来量化说明测试的充分度。覆盖率的前提是存在单元测试，并且从其本意上推导，可被统计覆盖率的单元测试应当是证明了软件正确的，这是一个不能动摇的基础，否则一切就失去意义。

单元测试重点在于验证软件正确，而覆盖率重点在于描述测试的充分程度，两者不会等同起来，但在项目和团队中一个普遍的认识是“高覆盖率的代码，其功能的正确性是得到保障的”。

一些骚操作：

覆盖率在持续集成中一般会作为代码准入的标准，这种选择来源于原则“没有测试覆盖的代码是不可靠的”以及它的变化衍生。大多数项目都会设定一个覆盖率的门限值，禁止无测试的代码合入同时还要警告覆盖率的降低。通常来说这么做是合理的，持续集成中覆盖率检查以一种显性的约束来规范开发人员使用单元测试保障开发代码的正确性，并让单元测试逐渐地变成开发习惯。不得不说，覆盖率检查对单元测试的普及起了十分积极的作用。

但对于开发人员来说可以使用一些奇淫技巧躲过这些限制，在走查代码的过程中发现了一些写法十分奇特的单元测试，类似下面代码：

public class GameTest {
    @Test
    public void testVerify() throws Exception {
        // given

        // when
        new Game("1234").verify("1234");
        // then
        
    }
}
这样的代码乍看是没有什么问题的，使用了测试框架，调用了被测对象的外部接口，覆盖率报告上也有体现，一句话——完美！

但如此完美的测试代码偏偏少了最重要的东西——对预期的判断，这就太糟糕了，因为成片的测试根本没有办法告诉开发人员他们写的代码究竟是否正确，既然没有了对错那么单元测试的意义又何在呢？