单元测试门户junit开发流程v3

1、门户 JUnit 开发流程 说明1：单元测试的入门知识3：请配置好 perties 中的uesserver 地址和 perties 中的 iserver，aserver，snsserv址，要保证各 url 和接口指向的地址可用hbserver，forumserver 地4：新建测试类时，注意包路径和类名称的格式com.test 这个是基本路径 datasource 表示是数据源（还有 action） portaluser 这个是子路径（同类名）如果类中包含很多方法，需要针对不同的方法， 分别写测试类，类名可为 methodTest（例如：5：代码注释经过一系列debug，ues 门户跑juni

2、t 用例时，最好注释掉 2 处代码：（涉及 2 个类）1：CachedFactory 中的init 方法中的2：BaseHttpTools 中的sendHttpRequestByHttpCnt 方法内部：和6：项目工程的路径，请尽量不要包含中文。否则初始化配置文件会报错2.2 数据源的单元测试一：新建测试类设置junit 相关选中要测试的方法得到测试类继承JUnit 基类（这个基类是专门为门户写的保证环境可以运行的类）并设置当前请求的request 和用户信息当前测试方法编写1：查看该数据源方法主要调用的接口2：针对该接口写测试桩3：最后一般是断言结束。4：若数据源包。参，则需要写多个测试方法

3、。执行test：查看结果：2.3 Action 的单元测试一：以 AddBlackListAction 为例，创建 test 类，并继承 BaseJunitTest 基类二：查看 action 内部调用的接口，并结合 action 最后的返回，得到不同的场景，然后创建不同的测试桩，test 不同的结果比如 AddBlackListAction 中，有 2 种结果，分别为跳转到成功页面和失败页面。对应的是snsserver 接口 addBlackUser 的成功和失败。所以测试方法需要写 2 个（如果失败的场景有具体的细分，比如接口的不同的异常码，这时就需要的测试方法）注意：1：如果action

4、 内部调用的接口为多个的话，就要组合不同的场景进试。2：action 的测试并非固定的，需要根据 action 内部的逻辑然后选用最合适的测试方法。1：成功的接口返回2：失败的接口返回测试方法-成功场景：（可以在方法名后面在场景标识：成功 or 失败 or 接口异常码）测试方法-失败场景执行结果：2.4 包含 DSF 接口的调用的单元测试1：查看代码可以看到，dsf 接口的调用，主要通过是：DSFserverAction 中的recordAction方法。这个方法内部有对测试桩的处理，所以涉及 dsf 接口的调用，junit 使用测试桩。2：继承BaseJunitTest，并写测试逻辑3：注意

5、 dsf 接口测试桩的 url 配置，包含 2 部分：一个是对response 的设置：(服务名.接口名.class) setSnsServerUrl(paymentServi rofile.class,.getDirectPaymentAccountPcom.jaguar.cgyment.response.GetDirectPaymentAccountProfileRsp);一个是 url 的设置：(服务名.接口名. erface)setSnsServerUrl(paymentServi rofile.erface,.getDirectPaymentAccountP4：测试桩：);5：查看运

6、行结果控制台：3：遗留问题和建议：1：没有启动memcache 相关2：由于门户的数据源方法较多，建议测试类名后+版本号+ 区分。 （见准备工作 2.1.4）3：有时测试时间会比较长，经查看发现是卡在 Class.forName4：会不自觉的启动定时任务，消耗内存-需要注释部分代码5：暂时没 dsf 接口的测试样例 （已补充 dsf 接口调用样例，见 2.4）6：日志暂时没有打印到控制台7：snsserver 接口调用，在一个测试过程中，一个接口只能写一个测试桩，不能针对一个接 口写多个测试桩（代码中对URL 固定了）-如果修复这个问题，需要改动代码（也可以不改动代码）7：snsserver

7、和 dsf 接口模拟测试桩的时候，一个接口只能写 一个测试桩（代码中写死了，会在 url 后面加上方法名），如果想解决，看下面的解决方案（4.4 和 4.5）8：一个潜在的死循环风险：在调用 http 接口时，会埋点日志相关（判断埋点日志开关是否打开），但是埋点日志开关是门户参数，也会调用接口，这样就导致了死循环的风险。（代码测试中发现循环了300 次后就取到值了，代码发现是由于缓存配置的maxThread=300，达到 300 后，会取默认值，然后设置到缓存中）-解决这个问题，需要注释掉埋点日志的代码（http 接口调用中的 2 处）4：开发过程中遇到的问题以及解决方案：1：JDK 版本问题

8、。请使用JDK1.8 版本，否则报错2：如果不识别test 目录下的java 类，需要添加路径3：加载缓存配置时，会启动定时任务（共 20 个），这段代码需要注释掉4：关于 snsserver 接口调用问题对于snsserver 接口调用，根据接口名称获取接口调用地址，代码是这样的：由于最后返回的结果在 url 的基础上追加了path，举例：setSnsServerUrl(addBlackUser, );这 样 根 据 上 面 的 方 法 ， 针 对 addBlackUser 这 个 接 口 获 取的 url 为可以通过： setSnsServerUrl(addBlackUser, )这样的话

9、，无需改动代码，但是，测试桩的接口名称的规范就变动了。5：dsf 模拟接口测试桩，也存在和上面 4 一样的问题：所以，需要： setSnsServerUrl(paymentServi rofile.class,.getDirectPaymentAccountPcom.jaguar.cgyment.response.GetDirectPaymentAccountProfileRsp);setSnsServerUrl(paymentServi.getDirectPaymentAccountProfile. erface,);最理想的情况是：setSnsServerUrl(addBlackUser,

10、 addBlackUser_1);所以，想要达到理想结果，需要改动 getApiUrl 这个方法。这样会造成代码污染。修改后的代码6：关于埋点日志引起的死循环问题启动初始化缓存和 dataload 时（CachedFactory.init()执行时），当Index=47 时，进入到 DBDtaLoader 时，会卡 3 秒钟左右。进一步发现是通过反射创建 MonthlyTiketDataLoader这个类的时候，在获取其静态不可改变的属性： LOADER_NUMBER （门户参数 book.monthly.ticket）引起的。更进一步发现，获取门户参数，最终是通过 GENERALINFOCACHE 的 dataload 调用接口获取的，而调用接，会判断埋点日志的开关是否打开，这个埋点日志开关，同样也是门户参数（buried_po _switch）。就这样，引起了（伪）死循环。幸好的是：GENERALINFOCACHE 缓存配置下面有这个配置：300。在 根 据 缓 存 名 称 获 取 获 取 value 时 ， Refresha