在java中我们经常会定义一些JavaBean的对象比如说 xxxDto, xxxVo等等。里面总是或多或少会出现getter setter的方法, 然后这些方法并不是业务测试人员真正关心的内容，同时这些方法往往还会降低覆盖率的情况。在github的issue中搜索了一番后，还真的找到了相关的信息。
Add filter for plain getter and setter
这个issue中将关于ant, cli, core, gradle等方式的逻辑都处理了， 例子如下：
private String name;
private boolean valid;
// Ignored because of the name 'getName' and the body
public String getName() {
return name;
}
// Ignored because of the name 'setName' and the body
public void setName(String name) {
this.name = name;
}
// Not ignored because of the custom body
public void setName(String name) {
if (name.length() > 0) {
this.name = name;
}
}
// Ignored because of the name 'isValid' and the body
public boolean isValid() {
return valid;
}
// Not ignored because of the custom name 'valid'
public boolean valid() {
return valid;
}
我们重点就看core这块的处理逻辑就好了。
public class PlainGetterAndSetterFilter implements IFilter {
public void filter(final MethodNode methodNode,
final IFilterContext context, final IFilterOutput output) {
if (isCandidate(methodNode, context)) {
output.ignore(methodNode.instructions.getFirst(),
methodNode.instructions.getLast());
}
}
...
}
代码主要是通过isCandidate来判断这个方法是否需要被忽略掉，不需要进行jacoco的方法处理。
private boolean isCandidate(final MethodNode methodNode,
final IFilterContext context) {
return methodNode.instructions.getFirst() != null
&& (isGetter(methodNode, context)
|| isSetter(methodNode, context));
}
private boolean dependsOnAttribute(final MethodNode methodNode,
final IFilterContext context, final int split) {
final String attributeName = methodNode.name.substring(split, split + 1)
.toLowerCase() + methodNode.name.substring(split + 1);
return context.getClassFields().contains(attributeName);
}
private boolean isGetter(final MethodNode methodNode,
final IFilterContext context) {
if (methodNode.name.startsWith("get") && methodNode.name.length() > 3) {
return dependsOnAttribute(methodNode, context, 3)
&& new GetterMatcher().match(methodNode);
} else if (methodNode.name.startsWith("is")
&& methodNode.name.length() > 2) {
return dependsOnAttribute(methodNode, context, 2)
&& new GetterMatcher().match(methodNode);
}
return false;
}
isCandidate 中判断了对应的方法是否是isGetter 或者 isSetter
关于判断是否是getter的逻辑其实不难, 这里主要是:
- 判断方法的名称是否是is或者get开头， 同时方法的名称剩余部分的名称必须是类的成员变量的名称一致。
-
new GetterMatcher().match(methodNode)方法体必须满足这个条件。
这里我们需要重点看下 GetterMatcher的逻辑
private static class GetterMatcher extends AbstractMatcher {
private boolean match(final MethodNode methodNode) {
firstIsALoad0(methodNode);
nextIs(Opcodes.GETFIELD);
nextIsReturn();
return cursor != null;
}
private void nextIsReturn() {
next();
if (cursor == null) {
return;
}
if (cursor.getOpcode() < Opcodes.IRETURN
|| cursor.getOpcode() > Opcodes.ARETURN) {
cursor = null;
}
}
}
这个内容看起来真的有点懵，因为这块其实是涉及到了字节码的逻辑了。这里讲起来其实很复杂， 所以我们就举个栗子来说明下：
package com.xx.dto;
public class AppDto {
private int jarStatus;
private int projectType;
public int getProjectType() {
return projectType;
}
public void setProjectType(int projectType) {
this.projectType = projectType;
}
public int getJarStatus() {
return jarStatus;
}
public void setJarStatus(int jarStatus) {
this.jarStatus = jarStatus;
}
}
假设我们现在有个类是这样子的，那么通过javac 编译以后，我们看到的字节码的内容是如何的呢？
我们可以针对编译后的class进行反编译进行查看
javap -c AppDto.class
就能得到如下的结果：
image
针对getProjectType 的方法内容 return projectType; 直接变成了
0: aload_0
1: getfield #2 // Field projectType:I
4: ireturn
再回来看match的逻辑就大概能够看懂了， 它其中已经严格要求了你的getter以及setter的具体逻辑是如何了。
所以我们思考下假设我们的getter方法是如下的是否能够被成功过滤掉呢？
public Date getUpdatedAt() {
return this.updatedAt == null ? new Date() : this.updatedAt;
}
很明显这个是不行的，我们不妨也反编译下看下具体的内容是怎么样的
image
已经不不符合我们的预期了。
