一位理想主义者对于测试的设想

玩转API

快速开启 - ApiHug如何在15分钟内，使用 ApiHug 启动一个API开发项目.https://apihug.com/zhCN-docs/start

📐设计先行

通过统一的API 设计元语(DSL, domain specific language), 让API 设计更语言化（Describe)；实现高度的一致化，和高复用。

📑协议驱动

OAS (OpenAPI specification), 是 ApiHug世界的 "金科玉律", 严格保证定义 ↔ 实现之间同构(isomorphism)态射。

🗺️单一信任源

实现 API 从：蓝图→施工→测试→落地，不走样， 不变形，不改味。极致沟通效率和极低信任成本。

❤️ 开发同理心

置身于多种角色,感同身受，在快和慢，现在和将来,个体和团队上综合平衡，极具同理心是ApiHug 人文基础，她不仅仅是一段代码，一个工具，一种方式。

Kola

大家都知道我要对测试下手了 :-),  在考察了九九八十二个方案后在放弃的边缘前(一入测试深似海,不如继续去搬砖)， 只能舍弃和妥协， 因为我们需要：

1.  简单，超级简单；do not make me learning!

2.  傻瓜，超级傻瓜，人人都能懂(业务方也能写，最后是模型给写), do not make me thinking

3. 不会(容易)犯错，想犯错也不行

4. 效率高，易维护

5. DSL, 静态校验；大家都知道我对DSL 比较推崇

6. IDE 支持(或者低成本改造)

7. 通用，和 1&2对应

8. 高度模块化、复用， 给老板们省钱

9. 各种人员友好

10. .....

最终选择了：

1. BDD 风格(标准)

2. Groovy DSL

3. java poet 定义动态代码

4. junit5 + rest-assured + assertj + json-path+wiremock 底座

为什么？

1. spring cloud contact 太难理解了，团队学习成本太高

2. karate ：IDEA 支持居然要钱，脚本用js 引擎，不符合java 范

3. cucumber：  嗯， 还有很多需要处理，实现和定义分裂

4. spock： 要点习惯迁移

此方案的优点：

1. 学习成本低

2. BDD 范能保留

3. 接近java语法

4. 模块化

5. 测试用例正规化管理

6. 服务端测试， 客户端mock 一并解决(spring cloud contract记大功)

缺点

1. Java poet 需要学习==但是spring 也是用poet生成代码的哦，所以不怕

2. 要效率更近一层，需要稍微改造IDEA：模版和语法提示，小case

3. 需要配套使用，否则威力大减

4. 支持中间件：MQ, DB,CACHE,UI,Perf,异步 etc

是不是很期待呢？