known issues involved by MDC

使用MDC时,希望每个请求的日志都能绑定到对应的trackingid上,但是往往事与愿违,存在以下两种不可控情况:

(1)现象: 一些日志始终绑定某个trackingid

使用第三方或者其他人提供的包时,其他人采用的是异步线程去实现的,这个时候,第一个请求会触发第一个线程建立起来,而第一个线程的trackingid会和第一个请求一样(创建的线程的threadlocal会继承创建者):

Thread的构造器实现

        if (parent.inheritableThreadLocals != null)
            this.inheritableThreadLocals =
                ThreadLocal.createInheritedMap(parent.inheritableThreadLocals);

这样导致,只要这个线程一直存在,就一直是和第一个请求一致。

因为callable或runnable的task内容不是自己可以控制的范畴,导致再无机会去修改。

	private static final ExecutorService pool= Executors.newFixedThreadPool(3);

	public static final String checkAsync(String checkItem) {
  
			checkFuture= pool.submit(new Callable(checkItem) {
				public String call() throws Exception {
					......  //第三方库,无法修改,如果是自己库,直接MDC.put("TrackingID", trackingID)既可修改,或者更标准的搞法(slf4j支持):

“In such cases, it is recommended that MDC.getCopyOfContextMap() is invoked on the original (master) thread before submitting a task to the executor. When the task runs, as its first action, it should invoke MDC.setContextMapValues() to associate the stored copy of the original MDC values with the new Executor managed thread.”

				}
			});

代码示例的情况没有太大危险,因为线程一旦创建,就不会消亡,所以最多某个首次请求,查询到的日志特别多,后面的请求对不上号。但是如果某个线程池是有timeout回收的,则有可能导致很多次请求查询到的trackingid日志都特别多。

解决方案,不想固定死某个trackingid,则调用那个api前clean掉mdc里的trackingid,这样创建的线程就不会带有,即既然不属于我一个人,干脆放弃。调用完再找回。但是这样修改后,调用过程的log就都没有trackingid了。所以很难完美解决,要么有很多且对不上号的,要么一个都没有。

(2)现象:某个请求中,tracking中途丢失了或者变成别的了。

这是因为调用了第三方库,而第三库做了一些特殊处理,比如


	public String call(String checkItem) { 
              call(checkItem, null)
        }
	public String call(String checkItem, Map config) { 
                        String trackingID = config.get("TrackingID");
                        if(trackingID == null)
                              trackingID = "";
                        MDC.put("TrackingID", trackingID);  //因为没有显示trackingid来调用,导致后面的这段逻辑把之前设置的trackingid给清空了(="")。
                        ......
        }
        

解决方案: 方案(1)显式传入trackingid。而不是直接调用call(String checkItem); 方案(2)既然使用mdc,为什么不去check下mdc里面实现是不是有值,如果有,也算传入了,而不是直接覆盖掉。

以上问题很容易出现在第三方库的调用上,且如果不看代码,很难预知会出现什么清空或一直绑定某个。不管哪种情况,都要意识到所以使用mdc不是完美的,因为很多第三库的调用对于你而言都是不透明且不可修改的。

how to learn unit test mock framework

每次使用各种形形色色的单元测试Mock框架都比较晕,因为写的不够多,等学会了,又流行了一个新的框架,思考为什么老是记不住以及为什么每次都不能胸有成竹的说自己掌握了,想想估计是因为每次都是现学现用,比较零散,不成体系,所以写下这个记录,汇总下到底应该学习,一方面可以帮助在新学一个单元测试mock框架的时候,按照这个顺序学,学完之后,按照这个步骤写CASE;另一方面在使用mockito/powermock时,直接根据场景复制代码。

必知必会(一)- 搞出“假”对象

既然是单元测试的Mock使用, 第一步要学的是怎么搞出一个假的对象,然后后续工作其实都是围绕这个假对象做文章。

根据应用场景不同可以划分为2种方式:

(1)Mock: 制造一个完全的假对象;

根据策略的不同,可以定义不同默认行为的假对象,例如:

所有方法不进行任何真实调用,都统一返回null;

Apple apple= Mockito.mock(Apple.class);

所有方法调用是真实调用

Apple apple= Mockito.mock(Apple.class,Mockito.CALLS_REAL_METHODS);

(2)Spy: 制造一个假对象,但是是基于已有一个真实的对象。

满足的需求是,大多方法想用真实实例来调用,只想定制实例内部的一些方法。

Apple apple = new Apple();
Apple spiedApple= Mockito.spy(apple);

必知必会(二)- 绑定上“假”对象

第一步搞出假对象后,不会就自动使用上了,否则别人不需要用mock的测试怎么测?所以第二步要做的是让自己的Mock对象使用上,即绑定上被测目标和mocked对象,思考一个类如何使用另外一个类:

1 被测目标自己不创建,而是需要使用者传递进去的方式:

(a)作为构造器参数直接传递进去;
(b)使用Set系方法传递进去;

2 被测目标负责创建

本质上创建都是new的过程(PS:除了静态类), 所以mock掉new,让new返回要mocked的对象,就搞定所有的事情,但是从被测目标看,不可能都是new,可能这个new离被测目标还是有一定的距离:例如使用工厂类,使用spring的@autowire的等等,所以从代码层次看有以下几种情况:

(1) Apple apple = new Apple();
(2) apple = AppleFactory.getIntance();
(3)
@Autowired
private Apple apple;

(a)针对直接new的方式:让new出一个对象都返回mock的实例

class AppleTree{

private Apple apple= new Apple();

}

@RunWith(PowerMockRunner.class)
@PrepareForTest({AppleTree.class}) //don't miss this statement and pay more attention it is caller for Apple, not Apple.
public class TestNewObject { 

@Test
public void test() throws Exception {
Apple apple= Mockito.mock(Apple.class);
PowerMockito.whenNew(Apple.class).withNoArguments().thenReturn(apple);
}

(b)针对使用其他类来创建:mock创建方法

一般都是静态工厂这种情况,如果不是“静态工厂”,是另外一个实例的普通方法创建的,则需要mock那个实例了。
这里仅考虑一般情况,即面对静态工厂方法,mockito暂时不支持静态类的mock,所以需要结合powermock:

@RunWith(PowerMockRunner.class)
@PrepareForTest({AppleFactory.class}) //don't miss this statement
public class TestStaticMethod {

@Test
public void test() throws Exception {
Apple apple= Mockito.mock(Apple.class);
PowerMockito.mockStatic(AppleFactory.class);
PowerMockito.when(AppleFactory.getInstance())
.thenReturn(apple);
}

(c)还有一种情况是使用框架自动创建的,例如使用Spring的@Autowired
此时可以使用JAVA反射来直接设置进去,但是既然是使用mock工具,也可以使用标准点的方式,例如:

Apple apple= Mockito.mock(Apple.class);
Whitebox.setInternalState(testAppleInstance, "apple", apple);

必知必会(三)- Mock对象上做文章-伪造行为

学完前面2步后,就可以开始考虑干活了,既然搞出假的mock对象,不可能不去做一些“假动作”: 匹配上一个方法,然后做出一个行为:

其中匹配包括2种:

粗略匹配:

Mockito.when(mockedApple.getOwner(Mockito.anyString()).thenReturn("tom");

note: Mockito.anyString()不能匹配null的情况,此时需要用更普适的Mockito.any().

精确匹配:

Mockito.when(mockedApple.getOwner(Mockito.eq("somegstring"))).thenReturn("tom");

行为包括以下三种:

(1) 定义方法非真实调用;

设置其返回值:

Mockito.when(mockedApple.getOwner()).thenReturn("tom");

设置其抛出异常:

Mockito.when(mockedApple.getOwner()).thenThrow(new RuntimeException());

(2)定义方法去进行真实调用:

Mockito.when(mockedApple.getNumbers()).thenCallRealMethod();

对于不同的mock框架,可能还提供另外一些模式,例如mockito:

提供另外一种使用模式Mockito.[action].When:Mockito.doNothing()/Mockito.doCallRealMethod/Mockito.doReturn/Mockito.doThrow

这种模式适合没有返回值的方法调用,因为Mockito.when需要接带返回值的方法调用,而这种模式可以如下使用:

Mockito.doNothing().when(mockedApple).someVoidCall(Mockito.any());

(3)自适应变化:

例如设置每次返回的不同可以使用:

 when(mockedApple.getOwner())
  .thenReturn("one")  //第一次行为
  .thenCallRealMethod() //第二次行为
  .thenThrow(new RuntimeException()); //第三次行为

其他形式的各种高级搞法,不考虑。

必知必会(四)- Mock对象上做文章-验证行为

不考虑本身case就可以写出验证点,有时候需要验证一些mocked对象上的行为来验证case是否成功,按照需要验证的要点来看:
(1)验证调用与否或调用次数

 Mockito.verify(mockedApple, Mockito.times(2)).someMethod(Mockito.anyString());
 Mockito.verify(mockedApple, Mockito.never()).someMethod(Mockito.anyString());

(2) 验证调用时间

 Mockito.verify(mockedApple, Mockito.timeout(10)).someMethod(Mockito.anyString());

(3)验证调用参数值

方式1:Matcher-直接验证参数

简单校验:

 Mockito.verify(mockedApple, times(2)).someMethod(Mockito.eq("expectedString")); //mockito要求此处不能直接写"expectedString"

自动义校验方法:

使用Mockito.argThat+ArgumentMatcher(Matchers.argThat(Matcher matcher)
):

Mockito.verify(mockedApple).someMethod(Mockito.argThat(new ArgumentMatcher<String>(){
			@Override
			public boolean matches(String argument) {
		    	return argument.equals("expectedString");
}}));

方式2:Captor-捕获出参数,然后校验

使用ArgumentCaptor捕获参数,然后进一步处理的

ArgumentCaptor<String> argument = ArgumentCaptor.forClass(String.class);
Mockito.verify(mockedApple).someMethod(argument.capture());
String value = argument.getValue();
Assert.assertEqual(value, expectedString);

区别:
Also, sometimes ArgumentCaptor may be a better fit than custom matcher. For example, if custom argument matcher is not likely to be reused or you just need it to assert on argument values to complete verification of behavior.

(4) 验证调用顺序

主要包括两种,一种是同一个mock对象的方法调用顺序,另外一种是跨mock对象的方法调用顺序验证,分别参考一下两种示例:

InOrder inOrder = Mockito.inOrder(mockedApple);
inOrder.verify(mockedApple).firstMethodCallName();
inOrder.verify(mockedApple).secondMethodCallName();
InOrder inOrder = Mockito.inOrder(mockedApple,mockedOrange);
inOrder.verify(mockedApple).methodCallName();
inOrder.verify(mockedOrange).methodCallName();

对于各种验证,有时候需要reset mock对象,以便处理共享等问题,可以使用Mockito.reset()。

总结:

对于一个新的单元测试框架大体要搞清楚几件事情:“伪造对象-绑定对象-定制对象动作-验证” ,核心关键是mock/spy it then when customized match one method do something and verify after executed写具体case的时候,也可以follow四个步骤来搞。另外上面演示的都是基本要点,其他都是各种形式的变种或高级用法,同时每种框架都有自己的特殊要求,必须遵从。