关于测试的一些思考（愚见）

单元测试与集成测试

关于Repository与Mapper单元测试与集成测试的权衡，理论上应由集成测试覆盖mapper，单元测试覆盖全部Repository。但实际开发中存在大量的Repository只是单纯的简单调用Mapper，无任何逻辑。对于这样的Repository，若是开发时间紧张且需求变动不频繁，能够直接在Repository层直接编写集成测试来保证测试覆盖。但对于存在业务逻辑的Repository，仍建议使用单元测试进行覆盖。且单元测试执行时间远小于执行集成测试时间，编写大量含有业务逻辑的Repository的集成测试会增长测试执行时间，致使开发人员下降对编写测试的意愿，增长流水线/CI/CD测试执行时间。

以此类推，建议对于简单逻辑的代码，无需花费过多的时间编写重复逻辑的单元测试与集成测试。但对于较为重要的系统组件代码，仍建议进行高粒度和多层次的测试覆盖。

测试对重构的影响

理论上对无测试或测试覆盖度较低的代码进行重构具备较大的风险，很难保证重构先后对外暴露功能与重构前彻底一致。但过于细粒度的测试（好比过多重复逻辑的测试：集成测试与单元测试重复，不一样层次下集成测试屡次覆盖）会大大增长重构时对于测试代码的修改时间。从而致使下降开发人员重构意愿以及增长重构所需时间。尽管不一样层次的测试多重覆盖能增长软件的可靠性。但实际开发过程当中开发进度与软件可靠性的权衡仍值得项目管理人员考量。对于高测试覆盖率的重构，仍需测试人员进行重复测试。不能仅经过开发人员提供的测试报告就认为重构先后软件对外功能表现彻底一致。

人工审查代码经常能检查出测试代码不能检查出的问题

没有100%可靠的软件，仅靠开发人员编写的单元测试、组件测试、集成测试不能彻底保证软件的可靠性。哪怕对于测试覆盖率100%的代码，仍有可能存在未覆盖到的业务场景。测试覆盖只能保证每一行代码都被执行到，每个分支都被覆盖到。然而来自第三方的输入却没法穷举；多种分支的组合爆炸也使业务逻辑的彻底覆盖会消耗开发人员大量的时间；业务系统上线后，也可能会出现各类意想不到的脏数据。不能彻底的相信开发人员测试覆盖的报告（如Jacoco高测试覆盖率，CI/CD变绿经过）就能保证其交付软件的可靠性。所以，开发人员之间的Code Review，测试人员的手工测试，上线以前各部门之间的联调仍有很大的意义。

TDD不是万能的/反对教条主义

相比一些开发者对于TDD的狂热，我认为TDD并非万能的。TDD是一种好的思想，可以帮助咱们拆分Task，划分任务，理清需求，提高开发速度和软件质量。但在实际开发任务中，我建议在保证软件质量的前提下，无需严苛遵照TDD教条。好比对于算法等探索类项目，网络爬虫项目，细粒度的TDD开发只会下降开发效率，在测试与开发代码之间反复来回修改，徒耗时间。对于这类软件，建议明确需求后先写实现再补全测试。对于简单逻辑，能够在上层进行集成测试，无需自顶向下编写大量仅仅简单的直接调用的测试（如Controller->Service->Repository->Mapper）。对于一些过于严苛（在我看来）的教条，好比每次只编写一条测试，而后红绿实现；若是存在大量的相近测试场景，好比第三方输入的验证。若存在多种格式的校验，我的认为无必要单条测试与业务实现一对一进行，在明确Task后彻底能够编写多条test后一并实现，可以必定程度上避免业务代码的反复的简单修改。TDD思想应该是保证软件的可靠性和健壮性，不该是开发效率的阻碍。哪怕是彻底TDD驱动出的代码，仍建议开发者人工的对逻辑进行审查。开发人员除了相信绿色的CI/CD，也应当相信本身的眼睛和大脑。

总之对于测试驱动开发而言，我的认为没有严格意义的执行教条，测试驱动开发是一种指导思想，是软件质量的保证，但不该当是开发进度和效率的阻塞。