TDD之团队单元测试规范

近期，给项目化开发人员做技能培训时，整理了一下团队在DOD中对于单元测试最佳实践和要求，作为单元测试规范，如下：

一年来的成果，为团队点赞

---

【原则】开发人员在编写代码过程中需要恪守的基本准则，在日常工作中需要在基本原则的指导下完成代码开发任务。-【价值观】

【规则】开发人员在日常开发过程中必须严格遵守的规则，这是系统代码得以正常稳定运行的基础，是以团队合作方式进行软件开发的基本保证。-【大家都认可都必须这么干】

【建议】建议部分提出的内容，希望员工能够尽量遵守，这些内容是经验丰富的开发人员在长期开发中积累的宝贵经验教训，有助于编写出高质量的代码。-【尽量这么干】

【原则1】遵循TDD三原则（定律）

-没有用例失败时，不要写产品代码

-当有用例失败时，不要写更多的用例

-仅写让用例通过的代码

【原则2】TDD遵循测试的FIRST原则

F(Fast)：测试要能快速运行

I(Isolate)：测试用例要独立，不能相互依赖

R(Repeatable)：测试要可以重复运行

S(Self-verifying)：测试会自己检查产出

T(Timely)：测试要及时做，与写代码紧密相连

【原则3】TDD是开发行为，是DOD

TDD是开发必须的基本技能

交流的基本语言

DoD-开发完成的定义，团队成员认可，不断扩充

【原则4】代码是债务，单元测试用例也是，优先修复并且不断重构

【规则1】每一个用例测试一个概念/功能

测试用例遵循SRP。当测试失败时，很容易知道用例失败的原因。

【规则2】测试名称遵循BDD（Gievn-When-Then）书写模型：Given/When/Then

假如[当测试开始时，系统所处状态的一些重要特征]，当[用户执行某些动作后]，那么[系统新的状态的一些特征]

TEST(RecurrNonProrateStateChangeReactiveTest, GivenFeeIs100$PerMonthAndBenefit100SMS_WhenReactiveAt20thJanuary_ThenDeduct100$AndBenefit100SMS)

【规则3】测试用例按照构造数据/执行功能/检测结果进行代码分块

用例编写也遵循BDD（Gievn-When-Then）书写模型。并按照构造数据/执行功能/检测结果分块。

【规则4】将具有相同测试环境的用例放在同一个测试套件中

将构造测试环境及清理测试环境的代码分别放在 Setup及 Teardown 中，可以消除重复的代码，实现代码的最大可复用性。

【建议1】用例业务场景复杂时，可以通过注释提高可读性

除了用例名称，可以通过注释可以详细描述用例的测试场景。

用例注释

【建议2】通过用例套件来测试跨进程间的协议正确性

例子：SY测试时，OCPro生成内部消息，转发给你进程sydealsnr来处理。可以在一个套件来测试这两个用例，并严重接口。

TEST_F(TTest_OcproSendSNRMsg, GivenTriggerPCRF_WhenOcproUSURating_ThenOcproSendSnrMsgSucessful)

TEST_F(TTest_OcproSendSNRMsg, GivenSySpInfo_WhenSyDealSnrReceiveMsgFromOcpro_ThenReturnSnrAVPSucessful)

【建议3】用例代码和业务代码独立，并且建立对应目录，在内部可以按照业务分层建立目录。

【建议4】每个用例套件一个独立的CPP文件。用例公用代码文件以gtest_来区分业务代码。

【建议5】用例数据保持无关，保证可以并行执行，提高运行速度

因为历史原因或者特殊原因，无法做到数据独立，用例非utest_开头，优先串行执行；文件名以utest_前缀的用例程序并行执行。

【建议6】为了方便验证功能，某些特殊场景也可以直接测试private和protected函数

在对应头文件包含前加上转移说明

#include "gtest/gtest.h"

#define private public

#define protected public

#include "DAOInterface.h"

---

因为每个未证明正确的代码都是有嫌疑的，因此新增单元测试用例的最佳时机就是新增功能和修复功能之前。

TDD