在上一篇文章中已经概述了软件服务源代码的版本管理，那么接下来就是软件服务的构建与测试了，它决定了软件的稳定性和健壮性。这篇文章会谈谈我对软件服务测试构建的看法
软件的测试与构建
在我看来，软件的测试有几个部分组成：
- 单元测试：这是对开发完成自己相应功能的逻辑测试，它仅仅只是测试代码的运行逻辑。
- 集成测试：这是对开发完成自己相应功能的业务逻辑测试，它标志着开发的功能是否符合业务需求。
- UAT测试：在UAT环境中对功能进行真实的测试，它标志着开发的功能是否能上产线。
软件构建的方式很多，不同的语言构建的工具也不尽相同，但是最终都需要把构建的制品存放在制品仓库中，存放的制品方式也有2种：
- Monorepo：所有类型的制品都由统一的仓库管理
- Polyrepo：不同的制品存放在不同的仓库中
软件的测试
单元测试
这对开发者来说往往会觉得很繁复，因为对于单元测试，也是需要额外的单元测试代码，但是对于程序来说无疑可以保证其稳定性的。我觉得这个可以根据应用的大小来看待，如果是团队开发，这个时间成本是值得投入的，如果只是个人开发，我相信很多本地测试后就应该可以了。
单元测试在代码提交的工作流中也是非常必要的一环，当开发者提交了自己的功能分支并创建了一个Pull Request后，就应该触发相应的校验和测试流程，这也是你的PR是否能合并到开发分支的指标之一。
集成测试
对于微服务架构，它代表的是各个服务之间是否能正确的协作并完成业务逻辑测试，对于单一应用是各个模块之间能否正确的协作。
集成测试会涉及到具体的业务流程，这里需要很多的模拟数据来模拟真实的业务场景，这对开发人员来说也是一个挑战，特别是对于微服务，开发人员可能只对自己负责的业务熟悉，那么对于具体的真实场景，就需要实际使用者来参与其中了，比如产品业务员，项目经理或者产品经理，亦或是需求分析师。 我觉得这里就需要跨部门的合作了，业务部分需要和开发部门一起来确定模拟业务的这些测试数据，已经测试流程，然后根据具体的测试流程让开发自动化这些集成测试并根据业务场景的迭代而迭代。
UAT测试
我们假定集成测试已经覆盖了大部分的应用场景，UAT测试应该是一个和产线环境一样的环境，并由最终客户或者代表用户的测试人员进行相关的测试，在这里发现的问题修复以后，通过UAT测试的功能才有了具备上线的资格。
但是在现实中，要完成这些测试需要大量的人力成本和资源成本，对于大型的应用来说，这是非常必要的，一系列的测试都是一道道门槛来保证最终线上产品的稳定和可用，对于小公司来说也应该尽量保证有一个人为可测试的沙盒环境作为产线的最后一道保障。
软件的构建仓库
Monorepo
将所有的构建制品存放在一个仓库中，这样的好处是方便管理，构建的依赖以及产品的部署都使用统一的入口，但是不好的地方是一个统一的仓库对负载要求很高，而且一旦瘫痪所有的构建和发布都会收到影响。
Polyrepo
将不同类型的构建品存放在各自的仓库中，相较与Monorepo，它不需要那么高的负载，而且其中一个仓库出现问题也不会影响别的仓库，但是对于运维团队来说却增加了额外的工作量。
如何选择
这里有2种情况：
- 如果仓库是自建维护，我是比较倾向于选择Polyrepo，遵循软件架构中的解耦思想，通过Polyrepo可以大大降低对单一仓库的依赖，即便需要维护多个仓库的时间这也是值得的，况且对于如今IAC(Infrastructure As Code)的趋势来说，这也大大降低了维护的成本，避免了手动维护中遇到的风险。
- 如果使用的付费的第三方仓库服务，我选择使用Monorepo。
据我所知的当前一般的制品仓库：