Coup de Grace

日后的测试代码要怎么写

本篇算是心血来潮,规划一下日后公司里的测试代码应该怎么搞下去.

目前觉得自己短短的职业生涯内呆的几个大的小的公司写的测试代码都不是我心里想要的那样,总结一点下班后的东西算是.

2016-07-07写就 2017-01-03重新编辑 更新了半年之后我的一些新想法.


本篇涉及的实践内容:

随缘更新,随时太监.


一些链接


单元/集成测试填坑

我们把时钟拨回看sharding-jdbc那天,我感慨了一下人家测试写得好.

那么就拿这个项目做单元测试和集成测试的例子.

主要思路就是拿Test Suite串起来所有的UT.

单元测试一般都是期待出现期待值的思路,那么其中外部对象或者异步操作就需要Mock.

这部分选型我更倾向于TestNG+PowerMock+AssertJ.

同时mvn的运行插件在基于Gitlab与Docker的CI有所体现.

几点:

数据驱动的接口测试

俗称DDD.

TestNG是自带@DataProvider的数据源配置的,可以自行实现数据源对象.

今天的主角就是这方面的扩展feed4testng.

一言概之:

@Test(dataProvider = "feeder")
@Source("xxxx.csv")

更浮夸一点的直接拿数据表做数据源它也实现了,自行看看咯

再比如这种也都可以瞄一眼看看实现,自定义一些功能.

那么我们可以把这部分的接口测试也接入到上一节的UT中.


embedded 压测

我一直比较倾向于把压测套件放在程序中,或者是插件

这样RD可以随时看一下自己写的”切面”,”通用工具类”,”Controller Advice”之类的东西是不是导致程序调用越来越慢.

gatling就是这样一个好用的工具,由scala编写,录制一些脚本可以很方便的进行BDD与压测操作.

同时还自带了一份html报表.

另外就是wrk是我最近发现的压测工具,用起来比ab应该是好一点.


持续集成与持续交付

Circle CI这种云CI大体思路是给你一个云虚机,写yml配置文件来

同时我这里曾经写过,供参考.


webhook

项目地址

我使用的是这篇deploy-docker运行了一份实例.

具体教程我就不给出了,就是添机器,写脚本.

下面说下主要的问题:

我们的脚本什么样子:

mvn clean install -Dmaven.test.skip=true docekr:build docker:push

产生fatjar并且做成镜像push到了registry.

我们的Dockerfile在这里

FROM java:8-jre-alpine
RUN sed -i 's/dl-cdn.alpinelinux.org/mirrors.ustc.edu.cn/' /etc/apk/repositories
RUN apk update && apk add ca-certificates
RUN apk add tzdata
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime && echo "Asia/Shanghai" > /etc/timezone
VOLUME /tmp
ADD app-1.0-exec.jar app.jar
RUN sh -c 'touch /app.jar'
RUN echo $(date) > /image_built_at
EXPOSE 8080
ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-Xms4096m","-Xmx4096m","-Xmn2048m","-XX:MaxDirectMemorySize=2048m","-XX:MetaspaceSize=128m","-XX:MaxMetaspaceSize=512m","-XX:ReservedCodeCacheSize=240M","-jar","/app.jar","--spring.profiles.active=${SPRING_PROFILES_ACTIVE}"]

git flow简述

这里有一篇工作流对比的文章,是Atlassian的.

Enhance-Gitflow是我写的一些,相对比国内的介绍详尽一点,更接近生产 .

另外关于merge与rebase,Atlassian还有一篇质量很高的文章.

说白了,rebase目的是优先处理来自其他分支的内容,再以之为基础进行merge.就是所谓的”变基”.

rebase只在本地分支用用就算了,优点是分支会很干净.突然的rebase就算不在master上也会导致被合并方莫名其妙.

科学点的套路: 将被合并方merge到合并方解决冲突,再merge回去.

另外这里有官方的github flow教程.


Mock Server

最近我改写了基于moco的mock-server搭建这篇,实际完全体形态不应该是这样的.

功能来讲参考美团的Mock Server实战我觉得没问题.

我们事先的过程中大概要考虑这几种调用方式:

实现的话,规则配置与mock访问分开为两块是应该的.

那么我们可以

另外要澄清的是Swagger算是简单的测试手段,但不具有更让人浮想联翩的功能.


App/UI自动化

写到这儿太监一下,手头有点别的事儿要做.

择日继续.

我这择日就择了半年啊…事实是生产环境上UI自动化收效甚微,我觉得投入产出比并不科学.


done.