上次发了那篇文章之后，有人和我说网络请求那边无法进行单元测试。
按照上一章的操作去执行肯定是跑不了网络请求模块的单元测试，平时如果对网络请求模块进行单元测试，能直接判断不同的入参会有那些结果，而不用运行程序，相对刚开始开发而言还是十分方便的。
所以这章就是为了补充上一章，简单聊聊为什么单元测试无法测试网络请求，然后我又是怎么处理的。
一.为什么单元测试无法测试网络请求
相同的问题有，为什么单元测试网络请求不走回调。
其实这个问题不是因为没有走回调方法，而是普通的单元测试的操作无法测试异步。可以说你的异步操作还没回调的时候，这个测试的方法就走完了。
网上有很多人说用CountDownLatch 的await()方法可以解决，我自己试了下发现是没效果的。
二.解决方法
其实不用考虑这么多，直接把异步改成同步就行，测试的时候把方法的异步改成同步测试，测试完之后再把同步改成异步。比如我用okhttp的话，原本的异步是这样写
callback = new CallBack { ...... }
call.enqueue(callback );
改成
Response response = call.execute();
String result = response.body().string();
callBack.onResponse(result);
然后在测试类中写测试方法
@Test
public void doPost() {
Map<String, Object> params = new HashMap<>();
params.put("aaa", "aaa");
params.put("bbb", "bbb");
httpHelper.doPost(myurl, (HashMap) params, new HttpCallBack<TestEntity>() {
@Override
public void onSuccess(TestEntity data, int code, String message) {
assertEquals(new TestEntity(),data);
}
});
}
这样assertEquals肯定失败，比较对象的话会是去比较地址，但是我们又总不能把对象里面的一个个属性都拿出来对比吧，这样好蠢。
这就是我这篇说的另一个重点。平时我们开发运行时最好的测试方法是什么，没错，是断点，一个能把断点玩得熟练的人，不仅仅是打断点看数据这么简单，还可以在断点除加打印和替换值等操作，但是那都是运行时的操作。
不过我们的单元测试也同样可以打断点，而且打断点的方式和开发时打断点一样。打完后点击方法左边的开始按钮可以选择debug模式，之后的操作就和普通debug的操作一样。
要判断数据，可以在onSuccess方法处打断点，这样就能够明确的请求的返回值data的详细参数。
没错，单元测试的Debug模式就是这么强大，它能够省掉很多测试的时间。你还在每测试一个功能都重复的运行app吗？你还在每次测试的时候都只看日志打印吗？那你out了。
网友评论