Mutation Testing
一、Mutation Testing（以下简称MT）是什么？
通俗的讲就是UT的UT
MT修改部分源代码后，在改变后的源代码上运行UT，再比较修改前后的差别，检测UT是否覆盖了各种场景。
自己理解就是针对某些误写错误的，比如>=误写成了<=，UT可能覆盖不到，但MT可以覆盖到。
最重要的它能够提高UT的准确度，可以检测出即使UT覆盖100%，但是某些逻辑判断仍然无法覆盖到的情况，更有效的降低了bug出现的概率。
二、MT的原理
1.判断
【Mutation Testing】大于变大于等于，具体如下：
| 原始逻辑 | MT修改后逻辑 |
|---|---|
| < | <= |
| <= | < |
| > | >= |
| >= | > |
//源代码
if(a2.计算
| 原始逻辑 | MT修改后逻辑 |
|---|---|
| + | - |
| - | + |
| * | / |
| / | * |
| % | * |
| << | >> |
| >> | << |
| >>> | << |
//源代码
int a = b + c;
//被MT修改为
int a = b - c;
3.void方法 MT会直接注释掉某些void方法使之不运行
//源代码
public void someVoidMethod(int i){
//编码
}
public int foo() {
int i = 5;
someVoidMethod(i);
return i;
}
//被MT修改为
public void someVoidMethod(int i){
//编码
}
public int foo(){
int i =5;
return i;
}4.更多规则 更多规则可见，https://pitest.org/quickstart...
5.具体MT操作 MT的每一次代码修改都会生成一个Mutant，每一个UT会针对每一个Mutant运行，将运行结果与原始的代码的UT结果比较，如果修改后的UT结果和修改前的一致，就表明代码覆盖不够全面，会记录为Survive，如果结果不一致，记录为Killed，表示UT覆盖的比较全。类似于下两图的操作：
文章图片
文章图片
三、MT的配置
项目pom.xml增加以下配置，threads可以增加多线程运行MT，以降低运行时间；timestampedReports默认为true，每次运行MT都会生成一个时间戳的文件夹，修改为false表示直接在设置的根目录生成报告，不再创建时间戳文件夹
org.pitest
pitest-maven
1.6.3
10
**.*IT
xml
html
src/test/resources/mutationHistory
src/test/resources/mutationHistory
false
如果只修改了部分代码，需要单独运行MT，在以上配置中的configuration中增加以下内容，可以单独指定运行某个class的MT
com.a.b.c.AServiceImpl
com.a.b.c.AServiceImplTest
如果需要修改更加严格的MT测试，可以在configuration中增加以下内容，其中可以修改的油DEFAULTS，STRONGER，ALL，具体规则见https://pitest.org/quickstart...
DEFAULTS
执行命令进行MT
mvn org.pitest:pitest-maven:mutationCoverage本地运行MT，如果代码UT以及源代码较多，会耗时很久，因此需要通过上面的配置historyOutputFIle，每次执行完毕会生成历史文件，下次再次运行MT，只会运行有源代码变化的UT。缩短后期每次的执行时间。具体如下截图，内容是
文章图片
文章图片
四、运行完成的报告
绿色代表已经通过MT的覆盖，红色表示没有被覆盖
文章图片
文章图片
文章图片
五、我在针对MT测试的情况下如何写UT
覆盖要全，各个分支都要覆盖到，其实正常咱们自己写UT时候也应该默认覆盖到（KILLED），如果没有覆盖到会显示（SURVIVED）
//源代码
public String testMT (String code) {
if(code.equals("1")){
return "SUCCESS";
}
return "FAIL";
}
//UT
@Test
public void testMT(){
Assert.assertEquals("SUCCESS",mtDemo.testMT("1"));
Assert.assertEquals("FAIL",mtDemo.testMT("2"));
}如果某些逻辑情况下是throw出XXException时候，需要在test注解中增加以下内容，也能够覆盖MT
@Test（expected=XXException.class)源代码中尽量返回有意义的结果，避免使用void，返回void时，MT强行注释掉的情况，无论如何都无法通过断言去判断（其实感觉这种情况就是模拟在写代码的时候，完成了编写void的方法后，但是忘了在主方法中调用了的情况）。
//明确的返回可以断言判断
Assert.assertEquals("SUCCESS",mtDemo.testMT("1"));
if判断中有多个条件的，mock返回的需要覆盖到最后一个判断，下面图中显示支付和param2为1，但是param1不符合的时候就过了，MT就认为覆盖不够全main，但是UT修改后增加另外一种情况param1符合，param2不符合，正好完美覆盖，MT则表示Kill，提示覆盖完全
//源代码
public String testIf(String param1,String param2){
if("1".equals(param1) || "1".equals(param2)){
return "SUCCESS";
}else{
return "FAIL";
}
}
//UT
@Test
public void testIf(){
Assert.assertEquals("SUCCESS",mtDemo.testIf("0","1"));
}
文章图片
@Test
public void testIf(){
Assert.assertEquals("SUCCESS",mtDemo.testIf("0","1"));
Assert.assertEquals("SUCCESS",mtDemo.testIf("1","0"));
}
文章图片
还有一些复杂的情况，例如lambda，实际上也是要覆盖到不同的情况返回不同的结果
//源代码
static class TestDto{
private String name;
private String type;
TestDto(String name,String type){
this.name = name;
this.type = type;
}
public String getName(){
return this.name;
}
}
public List testLambda (List list) {
return list.stream()
.filter(l-> l.getName().equals("name1"))
.collect(Collectors.toList());
}
//UT，只覆盖了name1存在的情况，如果name1不存在情况没覆盖
@Test
public void testLambda(){
List list = new ArrayList<>();
MTDemo.TestDto dto1 = new MTDemo.TestDto("name1","type1");
MTDemo.TestDto dto2 = new MTDemo.TestDto("name2","type2");
list.add(dto1);
list.add(dto2);
Assert.assertEquals("name1",mtDemo.testLambda(list).get(0).getName());
}
这时MT会强制修改lambda中的fiter部分，直接改为treu/false生成两个Mutant，会有一种没有覆盖到，MT会标注SURVIVED
文章图片
//再增加一个UT，覆盖到name1不存在的情况
@Test
public void testLambda2(){
List list = new ArrayList<>();
MTDemo.TestDto dto2 = new MTDemo.TestDto("name2","type2");
list.add(dto2);
Assert.assertEquals(0,mtDemo.testLambda(list).size());
} 
文章图片
推荐阅读
- 一个人的旅行，三亚
- 一个小故事，我的思考。
- 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量
- 开学第一天（下）
- 一个人的碎碎念
- 2018年11月19日|2018年11月19日 星期一 亲子日记第144篇
- 遇到一哭二闹三打滚的孩子，怎么办┃山伯教育
- 第326天
- Y房东的后半生14
- 奔向你的城市