TDD 学习笔记

虾球xz

已于 2023-04-13 23:10:47 修改

阅读量271

点赞数

文章标签： tdd 学习笔记

于 2023-04-13 22:59:50 首次发布

本文链接：https://blog.csdn.net/TM1695648164/article/details/130142359

版权

测试驱动开发(Test-Driven Development, TDD)，或测试先行编程，是指在编写实现功能的代码之前，先编写自动化测试来验证所需的功能。这些测试一开始当然会失败。我们的目标是快速编写最少的代码使这些测试通过。最后，根据需要重构代码以优化或清理实现。TDD的一个重要方面是，变更是渐进进行的，以小步为单位。编写一个简短的测试，然后编写足够的代码使该测试通过，然后重复上述过程。每次小改动之后，都要重新编译代码并重新运行测试。在这些小步骤中工作意味着，如果测试开始失败，那么很可能是由于上次测试运行后编写的代码造成的。让我们看一个例子来说明这一点。我将从一个小测试开始，来验证电影打分class的行为。


#include <gmock/gmock.h>
TEST(MovieRatingTest, FindingNemo) {
    // 函数首先创建一个名为海底总动员的电影评分对象（MovieRating）
    MovieRating* nemo = new MovieRating("Finding Nemo");
    // 使用断言函数 AssertEqual 进行判断其评分数量是否为0（即不含有评分）
    EXPECT_EQ(nemo->GetRatingCount(), 0) << "no ratings";
}

在这里插入图片描述

有了这个初始的测试代码，您现在可以编写尽可能简单的代码来让测试通过。


#include <gmock/gmock.h>

class MovieRating {
   public:
    // 构造函数，用于初始化电影评分信息
    MovieRating(const std::string& name) {}
    // 获取电影评分数量的方法
    // 返回值：int，表示电影评分数量
    int GetRatingCount() const { return 0; }
};

TEST(MovieRatingTest, FindingNemo) {
    // 函数首先创建一个名为海底总动员的电影评分对象（MovieRating）
    MovieRating* nemo = new MovieRating("Finding Nemo");
    // 使用断言函数 AssertEqual 进行判断其评分数量是否为0（即不含有评分）
    EXPECT_EQ(nemo->GetRatingCount(), 0) << "no ratings";
}

这个API显然没有做很多事情，但它确实允许测试通过。所以现在可以继续添加更多的测试代码。


#include <gmock/gmock.h>

class MovieRating {
   public:
    // 构造函数，用于初始化电影评分信息
    MovieRating(const std::string& name) {}
    // 获取电影评分数量的方法
    // 返回值：int，表示电影评分数量
    int GetRatingCount() const { return 0; }
};

TEST(MovieRatingTest, FindingNemo) {
    // 函数首先创建一个名为海底总动员的电影评分对象（MovieRating）
    MovieRating* nemo = new MovieRating("Finding Nemo");
    // 添加两个评分
    nemo->AddRating(4.0f);
    nemo->AddRating(5.0f);
    // 使用断言函数 AssertEqual 进行判断其评分数量是否为0（即不含有评分）
    EXPECT_EQ(nemo->GetRatingCount(), 0) << "no ratings";
}

在这里插入图片描述

现在该编写最简单的代码，让这个测试通过了。


#include <gmock/gmock.h>

class MovieRating {
   public:
    // 构造函数，用于初始化电影评分信息
    MovieRating(const std::string& name) {}

    // 添加电影评分的方法
    // 参数：r，表示新增的电影评分
    void AddRating(float r) {}

    // 获取电影评分数量的方法
    // 返回值：int，表示电影评分数量
    int GetRatingCount() const { return 0; }
};

TEST(MovieRatingTest, FindingNemo) {
    // 函数首先创建一个名为海底总动员的电影评分对象（MovieRating）
    MovieRating* nemo = new MovieRating("Finding Nemo");
    // 添加两个评分
    nemo->AddRating(4.0f);
    nemo->AddRating(5.0f);
    // 使用断言函数 AssertEqual 进行判断其评分数量是否为0（即不含有评分）
    EXPECT_EQ(nemo->GetRatingCount(), 0) << "no ratings";
}

在这里插入图片描述

编写另一个测试将迫使我们使实现更通用。



void TestAverageRatingAndCount() {
    // 创建一个名为 "Cars" 的电影评分对象
    MovieRating *cars = new MovieRating("Cars");

    // 向电影评分对象添加三个评分
    cars->AddRating(3.0f);
    cars->AddRating(4.0f);
    cars->AddRating(5.0f);

    // 测试电影评分对象的评分总数是否为3
    AssertEqual(cars->GetRatingCount(), 3, "three ratings");

    // 测试电影评分对象的平均分是否为4.0
    AssertEqual(cars->GetAverageRating(), 4.0f, "cars avg rating");

    // 释放分配的内存
    delete cars;
}

现在应该扩展这个实现，让它返回添加的评分数以及这些评分的平均值。要做到这一点，最简单的方法是记录所有评分的当前总和以及加起来的评分数量。例如。


#include <gmock/gmock.h>

class MovieRating {
   public:
    // 构造函数，用于初始化电影评分信息
    MovieRating(const std::string& name) : mNumRatings(0), mRatingsSum(0.0f) {}

    // 获取电影评分的总数
    int GetRatingCount() const { return mNumRatings; }

    // 添加电影评分的方法
    // 参数：r，表示新增的电影评分
    void AddRating(float r) {
        mRatingsSum += r;  // 将新的评分加到评分总和中
        mNumRatings++;     // 将评分总数加1
    }

    // 获取电影评分的平均分
    float GetAverageRating() const {
        if (mNumRatings == 0) {
            return 0.0f;  // 如果评分总数为0，返回0分
        } else {
            return (mRatingsSum / mNumRatings);  // 计算并返回平均分
        }
    }

   private:
    int mNumRatings;    // 电影评分的总数
    float mRatingsSum;  // 电影评分的总和
};

TEST(MovieRatingTest, FindingNemo) {
    // 函数首先创建一个名为海底总动员的电影评分对象（MovieRating）
    MovieRating* nemo = new MovieRating("Finding Nemo");
    // 添加两个评分

    nemo->AddRating(4.0f);
    nemo->AddRating(5.0f);
    // 使用断言函数 AssertEqual 进行判断其评分数量是否为0（即不含有评分）
    EXPECT_EQ(nemo->GetRatingCount(), 2) << "no ratings";
}

TEST(MovieRatingTest, Cars) {
    // 创建一个名为汽车总动员的电影评分对象
    MovieRating* cars = new MovieRating("Cars");

    // 向电影评分对象添加三个评分
    cars->AddRating(3.0f);
    cars->AddRating(4.0f);
    cars->AddRating(5.0f);

    // 测试电影评分对象的评分总数是否为3
    EXPECT_EQ(cars->GetRatingCount(), 3) << "three ratings";

    // 测试电影评分对象的平均分是否为4.0
    EXPECT_EQ(cars->GetAverageRating(), 4.0f) << "cars avg rating";

    // 释放分配的内存
    delete cars;
}

显然，您可以通过添加进一步的测试来验证调用具有零评级的getaveragering()不会崩溃，并检查添加超出范围的评级值是否被适当地处理，但我认为您已经了解了一般原则。

测试驱动开发的一个主要好处是，它迫使在开始编写任何代码之前考虑API。还必须考虑如何使用API，也就是说，要站在客户的角度考虑问题。TDD的另一个作用是只实现测试需要的东西。换句话说，的测试决定了需要编写的代码。这可以帮助避免过早优化，并让专注于整体行为。

Stub and Mock Objects

有一种流行的技术可以让的单元测试更稳定，对故障也更有弹性，那就是创建可以代替系统中真实对象的测试对象。这让您可以用轻量级的可控替换来替换不可预测的资源，以达到测试的目的。不可预测资源的例子包括文件系统、外部数据库和网络。替身对象还可以用于测试在真实系统中难以模拟的错误条件，以及在特定时间触发的事件或基于随机数生成器的事件。

这些替身对象显然将呈现与它们模拟的真实对象相同的接口。然而，实现这些对象的方式有很多种。下面列出了一些选项，并介绍了每种情况的通用术语
假对象(Fake object):具有函数式行为，但使用更简单的实现来辅助测试的对象，例如，一个模拟与本地磁盘交互的内存文件系统。
桩对象(Stub object):返回已准备或已封装的响应的对象。例如，ReadFileAsString() 桩可能只是简单地返回一个硬编码的字符串作为文件的内容，而不是从磁盘上读取指定文件的内容。
模拟对象(Mock object):被插装的对象，它具有预先编程的行为，并对其方法的调用序列进行验证。例如，一个mock对象(或简单的mock)可以指定GetValue()函数在前两次调用时返回10，之后返回20。它还可以验证函数是否被调用了，比如只调用了3次或至少5次，或者类中的函数是按照给定的顺序调用的。

由于桩和mock之间的区别通常很难理解，让我们用一个例子来说明这一点。我将以儿童纸牌游戏《War》为例。这是一款简单的游戏，两名玩家平分一副牌。每个玩家都显示自己的顶牌，而拥有最大牌的玩家拿走两张牌。如果两张牌的值相等，每个玩家就放三张牌朝下，第四张朝上。值最大的牌赢得桌上所有的牌。玩家通过收集所有卡片来赢得游戏。我将用三个类对这个游戏建模:

Card:表示一张牌，可以将它的值与另一张牌进行比较。
Deck:保存一副牌，包含洗牌和发牌的函数
WarGame:管理游戏逻辑，使用函数来完成整个游戏并返回游戏的获胜者。
在实际游戏过程中，Deck对象将返回一张随机的牌。不过，出于测试的目的，可以创建一个桩牌组(stub deck)，以预定义的顺序返回卡片。假设WarGame对象接受一个deck对象作为其构造函数的参数，那么传入一个StubDeck对象就可以很容易地测试WarGame的逻辑。StubDeck对象定义了一个特定的、可重复的扑克牌序列。

这个StubDeck继承自真正的Deck类，这意味着必须把Deck设计成基类，也就是说，把析构函数和测试需要覆盖的方法都设为虚函数。下面是Deck类的声明示例。


#include <string>

class Card {
   public:
    // 默认构造函数
    Card() {}
    // 构造函数，通过名称创建一张牌
    explicit Card(const std::string& name) : mCard(name) {}

    // 获取牌的名称
    const std::string& Get() const { return mCard; }

   private:
    std::string mCard;
};

class Deck {
   public:
    // 构造函数，创建一副牌
    Deck();

    // 虚析构函数，用于释放动态分配的内存
    virtual ~Deck();

    // 洗牌函数，将牌堆中的牌打乱顺序
    virtual void Shuffle();

    // 返回牌堆中剩余的牌数
    virtual int RemainingCards();

    // 发一张牌，将牌堆中的一张牌移出，返回该牌
    virtual Card DealCard();
};

因此，StubDeck类可以继承自Deck类，重载Shuffle()方法，让它什么也不做，因为不想随机化牌的顺序。然后，StubDeck的构造函数就可以创建特定顺序的扑克牌。然而，这意味着桩类被硬编码为单个卡片顺序。更通用的解决方案是使用AddCard()方法扩展这个类。


class StubDeck : public Deck {
  public:
    void Shuffle() { std::cout << "StubDeck::Shuffle" << std::endl; };
    void AddCard(const Card &card) {
        // 将protected方法转换为public
        Deck::AddCard(card);
    }
};

然后，可以使用StubDeck编写多个测试，只需多次调用AddCard()，在传递给WarGame之前按照特定的纸牌顺序为它做准备。一种方法是在Deck基类中添加一个受保护的AddCard()方法(因为它会修改私有状态)，然后在StubDeck类中将这个方法公开为public。然后可以写


#include "wargame.h"

void TestWarGame() {
    // 创建一个桩牌堆对象，添加3张牌
    StubDeck deck;
    deck.AddCard("9C");
    deck.AddCard("2H");
    deck.AddCard("JS");

    // 创建一个战争游戏对象，传入桩牌堆对象
    WarGame game(deck);

    // 开始游戏
    game.Play();

    // 断言游戏胜者为玩家1
    AssertEqual(game.GetWinner(), WarGame::PLAYER_ONE);
}

这就是桩对象的样子(事实上，这甚至可以被认为是一个假对象，因为它提供了没有随机元素的完整功能)。现在让我们看看使用模拟对象进行测试是什么样子的。模拟对象和桩对象之间的主要区别之一是，模拟坚持进行行为验证。也就是说，模拟对象会记录对象的所有函数调用，并验证诸如调用函数的次数、传递给函数的参数或几个函数被调用的顺序等行为。手工编写执行这种检测的代码可能很乏味，而且容易出错。因此，最好依靠模拟测试框架来自动化这项工作。我将在这里使用谷歌模拟框架(http://code .google.com/p/googlemock/)来说明如何使用模拟来测试我们的WarGame类。您要做的第一件事是使用谷歌mock提供的方便宏来定义mock。


class MockDeck : public Deck {
  public:
    // 模拟洗牌函数
    MOCK_METHOD0(Shuffle, void());
    // 模拟返回剩余牌数函数
    MOCK_METHOD0(RemainingCards, int());
    // 模拟发牌函数
    MOCK_METHOD0(DealCard, Card());
};

MOCK_METHOD0宏用于检测没有参数的函数，Deck基类中的所有方法都是这种情况。如果方法只有一个参数，那么应该使用MOCK_METHOD1，以此类推。现在，让我们编写一个使用这个模拟的单元测试。因为我使用谷歌Mock来创建我们的Mock，所以我也将使用谷歌Test作为测试框架。这看起来像这样


TEST(WarGame, Test1) {
    MockDeck deck;
    // 断言洗牌函数至少被调用一次
    EXPECT_CALL(deck, Shuffle()).Times(AtLeast(1));
    // 断言发牌函数被调用3次，分别返回JS、2H、9C三张牌
    EXPECT_CALL(deck, DealCard())
        .Times(3)
        .WillOnce(Return(Card("JS")))
        .WillOnce(Return(Card("2H")))
        .WillOnce(Return(Card("9C")));
    WarGame game(deck);
    game.Play();
    // 断言玩家1获胜
    ASSERT_EQ(game.GetWinner(), WarGame::PLAYER_ONE);
}

巧妙之处在于这两行EXPECT_CALL()。第一个声明指出模拟对象的Shuffle()方法应该至少被调用一次，第二个声明指出DealCard()方法应该被调用3次，并且第一次调用将返回Card(" JS")，第二次调用将返回Card(“2H”)，以此类推。注意，这种方法意味着不需要为模拟对象公开AddCard()方法。模拟对象会在析构函数中隐式地验证所有的期望，如果其中任何一个没有满足，测试就会失败。

就这如何影响你的api设计而言，其中一个含义是，你可能希望考虑一个模型，将对不可预测资源的访问包含在一个基类中，并将其传递给worker类，例如前面给出的情况，将Deck对象传递给WarGame对象。这允许您使用继承在测试代码中替换桩或模拟版本。这本质上是依赖注入模式，依赖对象被传递到一个类中，而不是由这个类直接负责创建和存储这些对象。

Testing Private Code

有时需要编写单元测试访问类的私有成员，以实现完整的代码覆盖。给定一个名为MyClass的类，这可以用两种不同的方法完成:

成员函数:声明一个公开的MyClass::SelfTest()方法。
友元函数:创建一个函数MyClassSelfTest()，并在MyClass中声明它为友元函数。

如果MyClassSelfTest()函数和MyClass的实现在同一个库中定义，友元函数就相对安全了，这样客户端就不用在自己的代码中重新定义函数了。值得注意的是，谷歌测试框架提供了一个FRIEND_TEST()宏来支持这种友元函数测试。不过，因为这两种方法在功能上是等价的，而且除非绝对必要，否则我们一般都会避免使用友元函数，所以我将集中讨论第一种方法:在类中添加一个公开的SelfTest()方法，以测试类的内部细节，不过讨论也可以同样适用于友元函数的解决方案。

下面是一个简单的边界框类，其中包含一个自测试方法。


// bbox.h 用于表示包围盒（Bounding Box），即一个立方体（或矩形）的六面体外壳，用于包含实体或场景中的物体
class BBox {
  public:
    BBox();                               // 默认构造函数
    BBox(const Point &a, const Point &b); // 用给定的两个点构造一个包围盒
    Point GetMin() const;                 // 获取包围盒的最小点
    Point GetMax() const;                 // 获取包围盒的最大点
    bool Contains(const Point &point) const; // 判断给定的点是否在包围盒内部
    bool Intersects(const BBox &bbox) const; // 判断给定的包围盒是否与当前包围盒相交
    double CenterDistance(const BBox &bbox) const; // 计算当前包围盒中心点与给定包围盒中心点的距离
    void SelfTest(); // 自测函数，用于测试包围盒是否正确构造
  private:
    Point CalcMin(const Point &a,
                  const Point &b); // 根据给定的两点计算最小点
    Point CalcMax(const Point &a, const Point &b); // 根据给定的两点计算最大点
    Point GetCenter();                             // 计算包围盒的中心点
    Point mMin, mMax; // 最小点和最大点
};

因此，可以在单元测试中直接调用SelfTest()方法，以便对各种私有方法进行额外的验证。这对于测试来说非常方便，尽管这种方法有一些不好的特性。换句话说，你必须使用一个客户端不应该调用的方法污染公开API，并且你可能会因为在BBox实现中嵌入测试代码而给库增加额外的臃肿。在第一种情况下，有一些方法可以阻止客户端使用此函数。一种简单的方法是添加一条注释，说明该方法不供公众使用。更进一步，你可以从你生成的任何API文档中删除该方法，这样用户永远不会看到对它的引用(当然，除非他们直接看到你的头信息)。要实现这一点，可以使用Doxygen工具，在函数声明周围加上\cond和\endcond命令。

至于自测函数可能会增加代码膨胀的问题，如果你觉得有必要，有两种方法可以解决这个问题。一种方法是在单元测试代码中实现SelfTest()方法，而不是在主API代码中，例如在test_bbox.cpp而不是bbox.cpp中。在.h文件中声明了一个方法并不意味着必须定义它。然而，这也带来了与使用“friends”类似的安全漏洞。也就是说，客户端可以在自己的代码中定义SelfTest()方法，以修改对象的内部状态。虽然这个函数的接口限制了它们可以做什么，因为它们不能传递任何参数或接收任何结果，但它们仍然可以使用全局变量来规避这一点。


// bbox.cpp
...
void SelfTest()
{
#ifdef TEST
    // lots of test code
#else
    std::cout << "Self-test code not compiled in." << std::endl;
#endif
}

这种方法的缺点是您必须构建两个版本的API:一个带有编译进来的自测代码(使用-DTEST或/DTEST编译)，另一个没有自测代码。如果额外的构建是一个问题，你可以将自测代码编译为调试版本的库，但从发布版本中删除它。

值得注意的是，如果您希望为C API提供一个自测试函数，那么这是一个简单得多的问题。例如，你可以在.c文件中定义一个外部链接的SelfTest()函数，即在Windows上用__declspec(dllexport)装饰的非静态函数，但在.h文件中不提供该函数的原型。然后在测试代码中声明函数原型，这样就可以在单元测试中调用该函数。这样，该函数就不会出现在头文件或任何API文档中。事实上，客户端发现调用的唯一方法是转储共享库中的所有公共符号。

代码覆盖率

代码覆盖工具让您精确地发现您的代码的哪些语句是由您的测试执行的，也就是说，这些工具可以用于将您的测试活动集中在您的代码库中尚未被测试覆盖的部分。
可以测量不同程度的代码覆盖率。我将参考下面的简单代码示例来定义它们。


void TestFunction(int a, int b) {
    if (a == 1) a++;      // Line 1
    int c = a * b;        // Line 2
    if (a > 10 && b != 0) // Line 3
        c *= 2;           // Line 4
    return a * c;         // Line 5
}

覆盖的函数。在这个最粗糙的代码覆盖级别中，只跟踪函数调用。在示例代码中，函数覆盖率只会记录TestFunction()是否至少被调用过一次。函数内部的控制流对函数代码覆盖结果没有影响。

行覆盖率。这种形式的代码覆盖测试是否达到了包含可执行语句的每一行代码。这个指标的一个限制可以在我们的代码示例的第1行中看到。即使不执行a++语句，行覆盖将认为第1行已100%执行;只有当控制流到达这一行时才重要。显然，你可以通过将if条件和a++语句放在单独的行上来绕过这个限制。

语句覆盖。此度量度量控制流是否至少到达每条可执行语句一次。这种形式的覆盖的主要限制是，它没有考虑控制结构中的表达式(如if、for、while或switch语句)可能产生的不同代码路径。例如，在我们的代码示例中，语句覆盖率将告诉我们第3行的条件是否为true，从而导致第4行执行。但是，它不会告诉我们条件是否为false，因为这个结果没有可执行代码。

基本块覆盖。基本块是一系列不能被分支的语句。也就是说，如果第一个语句被执行，那么块中所有剩余的语句也将被执行。本质上，基本块以分支、函数调用、throw或return结束。这可以被认为是声明覆盖的一个特殊情况，具有相同的好处和限制。

决定覆盖。这个代码覆盖率度量度量每个控制结构中的表达式的整体结果是否同时为true和false。这解决了语句覆盖率的主要不足，因为你将知道第3行的条件是否被求值为false。这也称为分支覆盖(branch coverage)。

条件覆盖。条件覆盖确定控制结构中的每个布尔子表达式是否被评估为true和false。在我们的示例中，这意味着必须使用a > 10、a <= 10、b != 0和b == 0来命中第3行。请注意，这并不一定意味着条件覆盖，因为这些事件发生的顺序可能会导致if语句的整体结果总是为false。

有很多程序可以测量c++代码的覆盖率。它们都支持上述指标的不同组合，通常是通过检测编译器生成的代码。这些工具大多是商业产品，尽管也有一些免费和开源的选项。
一个特别有用的特性是能够从分析中排除某些代码行，通常通过在这些代码行周围添加特殊注释来完成。这可以用来关闭正常情况下永远不会被覆盖的代码行，例如总是被覆盖的基类中的方法;尽管在这些情况下，如果被排除的代码在将来出现，那么覆盖率工具会抛出一个错误，这很重要，因为这可能标志着行为中出现了意想不到的变化。
另一个需要记住的问题是，通常应该在没有进行优化的编译版本上执行代码覆盖率分析，因为编译器会在优化期间重新排序或消除单独的代码行。
下面的列表提供了一些比较突出的代码覆盖率分析工具的简要调查

gcov 举例

以下是一个简单的代码示例，演示如何使用 gcov 工具进行测试覆盖率评估。

建立一个 example.c 源文件，其中包含一个加法函数 add()。


#include <stdio.h>

int add(int x, int y) {
    return x + y;
}

int main() {
    int result = add(4, 5);
    printf("result = %d\n", result);
    return 0;
}

编译源代码。执行以下命令


gcc -fprofile-arcs -ftest-coverage -o example example.c

这会生成一个可执行文件 example。

运行可执行文件并检查测试覆盖率数据。执行以下命令：


./example
gcov example.c

这会生成一个 example.c.gcov 文件，包含对源文件进行测试覆盖率的精确度信息。

检查测试覆盖率报告。安装 gcovr 工具，然后执行以下命令：


gcovr -r . --html --html-details -o coverage-report.html

这会在当前目录下生成一个名为 coverage-report.html 的文件，用于查看测试覆盖率报告。
在这里插入图片描述

在这里插入图片描述

虾球xz

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
TDD 学习笔记

测试驱动开发(Test-Driven Development, TDD)，或测试先行编程，是指在编写实现功能的代码之前，先编写自动化测试来验证所需的功能。这些测试一开始当然会失败。我们的目标是快速编写最少的代码使这些测试通过。最后，根据需要重构代码以优化或清理实现。TDD的一个重要方面是，变更是渐进进行的，以小步为单位。编写一个简短的测试，然后编写足够的代码使该测试通过，然后重复上述过程。每次小改动之后，都要重新编译代码并重新运行测试。
复制链接

扫一扫