retinder

离我遇到无法使用junit测试mvc项目的这个坑，已经过去2个月了。最近一段时间一直在忙版本的事情。基本无法抽身。jacoco的坑填完了，赶紧来填了这个坑。免得坑越来越多。之前提过。由于项目的特殊性。开发将多个组件（子系统间）的通信方式，用listener来实现了。即只要master在，下游子系统的设置就可以通过监听来实现。public class ApplicationListener imple

熟读唐诗三百首，不会吟来也会偷testng其实是一个很久远的框架了。核心组件大概是在05年写的。为什么选择读这么久远的源码。主要原因也是因为它的应用范围广泛，资料齐全，而且使用起来确实很灵活可靠。如果想自己设计一个自动化执行/性能测试的框架，这块的源代码还是很有启发作用的。粗略读完testng的代码，有几点让我印象深刻 精准的流程控制，简单可靠的核心引擎testng的核心运行引擎，就是tes

底层的testng，使用的多线程，是目前应用最为广泛的concurrent包。也就是默认的ThreadPoolExecutor线程池。关于这个线程池的使用，我们来看一个例子： ThreadUtil.execute().ExecutorService pooledExecutor = // Executors.newFixedThreadPool(threadPoolSize); n

两个问题**1、tesng的架构是如何实现灵活定制listener的？通过什么方式动态加载listener 2、listener是如何抽象定义出来的** 目前常用的有reportlistenr、retryanlyzer。 testng的listener是典型的面向过程的抽象。 IConfigurationListener、IConfigurationListener2 IExecutio

testng里边的注释是如何应用的？举最简单的两个例子：@Test 这个注解AnnotationHelper.findMethodsWithAnnotation { 这里做最基本的判断： 1、先把有注解的找出来 2、有注解的方法不能有返回值，只能是void 3、给所有的测试方法编号 }TestNGMethodFinder.getTestMethods–>T

上一篇大大概概的从整个执行的路径来理了一下。这一篇。着重看一下，testng这个框架的一个很重要的组成部分：自定义注释的使用。说起来，自定义注释在之前，我是完全不了解它是干嘛用的。直到某次心血来潮的面试。我记得那个是有赞的测试，上来就问我各种java编程的基础知识，其他都还了解，就是当时问了我一下自定义注释的东西。我表示完全没用过，后来才专门学习了解了一下。在testng里边有两个很重要的注释：

接着上文继续分析testRunner的privateRun的流程。 上一篇讲清楚了，测试方法执行前的一些准备工作。包括执行的方法，顺序等等。接下来要分析两个事情： 1、testrunner的上下文从何而来，如何定义的 2、测试结果是如何收集的，就是testresult的多线程处理/** * Run all the ITestNGMethods passed in through the

最近一直没有时间写博客。在做一个相当于外包的项目。因为项目终于卖出去了，忽悠到人用了。而且最近释放了一个资源。最近一直忙于测试。testng执行核心的几个类：xxxWorker、xxxRunner是配套的。runner的类，只要是定义执行的上下文。Worker就是实际要运行的类。testng定义了两层。一层是suite这个层面的。一层是每个@Test层面的。从图中可以看到。其中，testRun

身为一个只会后端的测试人员，自动化出来的报告总是testng的默认报告。或者稍微美化一点的reportng的报告。在现在这个只看脸的世界，显然是还不够的。推荐大家用一个新的报告框架，extentreport。如何跟testng集成，如何使用，大家可以参考[这里写链接内容](http://extentreports.com/)，或者直接在csdn里边搜索。各种教程，一抓一大把。这里不再赘述。这里是参

由于公司提供的自动化平台，能力太有限，在对目前已有的自动化做迁移。自己做了一套基于文件模板的接口自动化框架。核心就是直接从浏览器F12录制，或者postman的collection导入。直接获取请求跟回复。自动化只需要基于这些模板，修改其中的部分值，还有写一些自定义的断言就可以。背景先交到到这开发过程还是很顺利的，吭哧吭哧就撸完了基本的代码，文件读写，http请求发送接收。这些都是之前写好了的手

为何需要手脚架就我在项目中遇到的情况。愿意写接口文档的开发人员，可谓少之又少。大多数不是沉默以对，就是认为这本身是属于测试的工作，不应该摊到开发身上。但是如果要人工去一个个收集这些接口参数或者维护这些接口的变化，实际还是很难做到的，工作量不小。在团队大部分测试人员的技术没达到的情况下，更是无从开展。于是手脚架的作用就显示出来了。华山一条路？ 其实这个问题，有很多种解法。从技术上来讲说服开发，引

AssertJ是我目前见过的最强大的断言api，没有之一。官网传送门 为什么使用assertJ？ 1、流式断言，代码即用例，直观易懂。 举个例子： 传统的junit或者testng，判断一个字符串包不包括a跟b两个字符。要这么写 assertTrue(stringbuffer.contains("a") && stringbuffer....