【吐槽】最近写一些异步的服务发现测试用例也忒难写了

问题描述

最近在给rabbitmMQ客户端插件写测试用例的时候发现也太难去处理测试用例了，利用workerman event-loop的rabbitmq基础客户端Bunny在网络请求的时候使用的event-loop的add及timer，如果我需要mock或者捕获我的参数及结果的时候实在比较复杂，如果workerman的event-loop拥有基础事件，我能够注入一些回调函数来进行数据拦截的话可能会好一些；
不知道workerman啥时候有空完善分享一下测试，也可能需要我有时间的时候先为workerman补充测试用例了；

测试用例有挺多的好处，比如：

1. 在调整修改基础接口的时候可以清晰地知道我的本次修改是否可以向前兼容、是否满足我的预期，这样可以不用畏手畏脚地进行新特性的新增和旧功能的移除；
2. 在对workerman进行外围开发的时候，开发者可以知道本次的修改是否影响workerman基础功能，在开发上会比较放心；
3. 使用者对测试覆盖较全的应用会更有使用信心，测试用例本身也是使用手册，对于有代码阅读习惯的开发者能够更快地进行理解核心本身；

如果我来进行测试用例的补充和围绕测试做调整，这里有几个疑问：

1. workerman现目前的基础依赖有哪些？比如 PHP >=7.4
2. 我应该对workerman github库中的哪个分支进行开发调整？
3. 是否需要讨论，毕竟测试用例的撰写包含可能会对核心代码的调整，比如
   1. 增加用于测试推演的拦截事件、增加内部的public接口，例如：撰写_getEventLoop()等内部接口方法，但该方法仅用于测试，而不作为开放接口堆外使用；
   2. 是否有代码的开发规范及习惯，比如约定 下划线开头的即便是public方法也应为内部方法等

不知道亮哥是否有计划做 workerman 规范迭代的计划，比如制订一些约定，以便于workerman开源社区的开发者更好的参与开源开发？

当然以上仅为一些吐槽和建议，因为在我看来，非死抠条款的约定有利于开源的发展及代码维护，不论 workerman官方在某一天是否还会继续维护，整个PHP开源社区都可以依照相应的约定继续 “接盘”，包括延申的周边产品都可以“续命”，我个人认为这是一件百利无一害的规划内容。