iOS 单元测试之BDD与TDD

单元测试

单元测试每个开发者都了解，编写单元测试的目的在于可以通过测试用例自动发现程序某些缺陷，测试用例越丰富，涵盖地方越多，程序健壮性越强。很多开发者都是写完代码再考虑写单元测试，来确认代码结果是否符合预期。

TDD

TDD全称Test Drive Development，面向测试驱动开发。从名字可以得知，TDD是一套开发流程，测试驱动开发。流程是先确认好测试用例，再编写功能代码，通过单元测试之后再优化代码，优化之后代码再单元测试，不断重复以上步骤直到写出满意代码。

例子：https://leetcode-cn.com

在leetcode刷题的时候，leetcode已经为每道题提供好测试用例了，当通过所有测试用例之后，证明你的代码正确，然而你想继续挑战优化最小时间维度和空间复杂度的话，可以重构你的代码，当然，重构完也是要通过单元测试。
以上就是TDD的一个例子。

TDD缺点：
1:从开发流程来讲，需要先提供测试用例，再进行开发。但在紧凑业务开发过程中，一般是先开发后测试，测试人员最后才介入，如果先要提供测试用例，必定要需求一开始就要非常明确需求细节，要能在开发前完整提供测试用例，难度有点大。
2:TDD没有规定测试测试范围，意味着TDD也是针对某个函数或者某个功能展开的，无法保证整体设计准确性。

BDD

Behavior Driven Development，行为驱动开发。与TDD不同，BDD不关注单个函数或者功能，更注重整体设计的准确性。而且BDD的测试用例编写更接近自然语言，较为容易从需求文档转化为测试用例，更直观。

举例：
给一个登录页面需求，要求手机号为11位，手机号长度少于11位，则登录按钮置灰，且不可点击。

Simulator Screen Shot - iPhone 8 - 2021-12-05 at 22.38.51.png

将上述需求转化为BDD测试用例的话，为以下代码

describe(@"登录事件", ^{
    context(@"点击登录", ^{
        it(@"手机号长度符合要求", ^{
             // 测试实现（执行登录）
        });

        it(@"手机号长度短了", ^{
            // 测试实现（登录按钮变灰且不可点击）
        });
    });
});

BDD对比优点：可以将需求，设计，更容易转为测试用例，而且测试用例可读性强，可以当作文档使用，易于维护。

总结：

1，TDD和BDD与其说是测试方式，不如说是开发方式，区别在于你要测试的对象是什么，TDD针对函数，功能，BDD针对行为，流程。
2，BDD为TDD的进化版，都需要开发前提供测试用例。
2，基础类或者SDK的可以使用TDD，BDD更适合整体业务开发。