写点什么

getInteger 还是 getIntValue,这是一个问题

用户头像
FunTester
关注
发布于: 3 小时前

getInteger()getInteger()两个方法都是com.alibaba.fastjson.JSONObject中的两个方法,功能类似,从一个JSONObject对象中获取到某个keyvalue值,区别在于getInteger()返回的是一个integer类型的对象,而getInteger()返回int值,属于基础数据类型。


以此为引……

缘起

在我设计项目框架的时候,在标准项目基类接口中定义了一个非常重要的方法com.funtester.base.interfaces.IBase#isRight,该方法的功能是验证响应结果是否符合规范以及正确性,通常会验证响应体的业务返回值和响应体响应信息。这是一个针对改项目所有接口返回值的验证,不涉及业务。

错误示范

具体的实现方法,举例如下:


    /**     * 验证响应是否合法     *     * @param response 接口响应     * @return     */    @Override    public boolean isRight(JSONObject response) {        try {            return response.getIntValue("code") == 0;        } catch (Exception e) {            return false;        }    }
复制代码


  • 当然,这是一个错误的示范!

BUG 分析

在每个项目中,都会有固定的响应结构,通常来说会在公司层面统一响应结构。改项目的JSON结构响应中最外层的keycodemsgdata构成。该方法的逻辑就是从response最外层获取code的值,然后跟0对比。


但是在某些特殊情况下,响应结构发生变化,最外层已经没有code,如果isRight()接收到的正常的JSONObject对象,那么isRight()返回的依然是true,这与实际情况严重不符。

BUG 修复

正确的处理方式如下:


    /**     * 验证响应是否合法     *     * @param response 接口响应     * @return     */    @Override    public boolean isRight(JSONObject response) {        try {            return response.getInteger("code") == 0;        } catch (Exception e) {            return false;        }    }
复制代码


绝大多数情况下接口响应都是正常的,只有在响应错误(请求失败,HTTPcode错误等等)才会导致响应结构体发生变化,这也是这个 BUG 一直没出现的原因。这里可以再多加一层验证,对于HTTPcode验证。PS:在 FunTester 框架中,HTTPcode被保存在response在外层的FunTestervalue中。


    /**     * 验证响应是否合法     *     * @param response 接口响应     * @return     */    @Override    public boolean isRight(JSONObject response) {        try {            return response.getInteger("FunTester") == HttpStatus.SC_OK && response.getInteger("code") == 0;        } catch (Exception e) {            return false;        }    }
复制代码


如果我们还想对这个方法增加一个全局开关来控制验证结果的话,还可以增加一个判断条件。如下:


    /**     * 验证响应是否合法     *     * @param response 接口响应     * @return     */    @Override    public boolean isRight(JSONObject response) {        try {            return Common.VERIFY && response.getInteger("FunTester") == HttpStatus.SC_OK && response.getInteger("code") == 0;        } catch (Exception e) {            return false;        }    }
复制代码


添加Common.VERIFY条件的好处就是,在性能测试中可以避开一些业务验证。因为在做功能测试和自动化测试的过程中,会经常进行业务上的验证,在验证代码中,可能会涉及一些耗时的操作,这一点在性能测试中是需要避免的。

实践出真知

Demo1

正常使用中测试代码:


    public static void main(String[] args) throws IOException {        JSONObject json = getJson("code=0");        output(json.getInteger("code") == 0);        output(json.getIntValue("code") == 0);    }
复制代码


控制台输出:


INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16INFO-> trueINFO-> true
Process finished with exit code 0
复制代码


这里是看不出来两者的区别的。
## Demo2


出现 BUG 时候的测试代码:


    public static void main(String[] args) throws IOException {        JSONObject json = getJson("code=0");        output(json.getIntValue("co") == 0);        output(null == json.getInteger("co"));    }
复制代码


控制台输出:


INFO-> 当前用户:oker,工作目录:/Users/oker/IdeaProjects/funtester/,系统编码格式:UTF-8,系统Mac OS X版本:10.16INFO-> trueINFO-> true
Process finished with exit code 0
复制代码


Have Fun ~ Tester !

FunTester,一群有趣的灵魂,腾讯云 &Boss 认证作者,GDevOps 官方合作媒体。



发布于: 3 小时前阅读数: 8
用户头像

FunTester

关注

公众号:FunTester,Have Fun, Tester! 2020.10.20 加入

Have Fun,Tester!

评论

发布
暂无评论
getInteger还是getIntValue,这是一个问题