实践TDD的点滴——前置条件的准备

一支函数多个前置条件，由于逻辑代码是顺序编写的，这些条件如果分开测试，就存在第二条件测试时，就要确保让第一个条件成立（哪怕用MOCK方式都很烦），第四个条件需要前面三个条件成立，前置条件越多就越烦，如何解决这个问题。

例：玩家进入游戏世界的逻辑。
[color=blue](C++的语法，我尽量简化写，大家应该看得懂)[/color]

１、如果游戏世界人数超过1000，则进入失败。
２、如果playerName未找到，也就是没有创建过该player，则进入失败。
３、如果player所在的场景之前未添加到gameWorld，则进入失败。
４、如果该player已经进入游戏世界，则进入失败。

对应的类和成员函数简略为：

class GameWorld
{
public:
    bool enterPlayer(String playerName)
    {
    }
private:
    list<Player> m_playerExists;
};

现在我要为第4条逻辑编写测试代码，即：如果该player已经进入游戏世界，则进入失败。

[b]一种写法是：[/b]

gameWorld.enterPlayer(“jack”) ;

CPPUNIT_ASSERT( !gameWorld.enterPlayer(“jack”) );

这种写法要求第一次进入世界要能够成功，但进入世界需要满足另外三个条件。第1个条件比较容易满足，而第2条件就需要通过mock确保”jack”已经创建过，第3条件就需要再向gameWorld添加jack所在的场景。而添加场景需要去满足场景添加的条件。这样一来，这个测试的准备工作很多。很多都是之前在编写第１、２、３逻辑时都已经写过的代码。为了满足测试的独立性，我四个逻辑的测试代码是分开的，这一来就出现了重复的代码。

[b]第二种写法：[/b]

直接访问gameWorld的私有变量m_playerExists，添加一个名为”jack”的player对象。

这种写法最简单，特别在c++下只需要让测试类成为GameWorld的friend就可以访问私有变量了。但这种做法严重破坏了类的封装，如果已存在的玩家不是以list<Player>存放，重构成以map<string ,player>存放，那么测试代码也得改。照理类内部的代码重构不应该影响到测试代码才对。

[b]第三种写法：[/b]

为GameWorld添加一支isPlayerIn()的函数

virtual bool isPlayerIn(String playerName)
{
}

然后对gameWorld进行mock。

class GameWorldMock : public GameWorld
{
protected:
    virtual bool isPlayerIn(String playerName)
    {
        return true;
    }
};

这种写法较第二种好一些，同时也驱动extract method，但同样也存在不妥的地方。isPlayerIn在实际代码中并没有用到，应该是private的，但为了让测试代码mock，要改成是protected。当然你会说isPlayerIn开放成public都行，正好可以做为enterPlayer的后置检测条件。这里我同样有一个困惑，测试中的后置检测条件往往需要通过一些get函数来提供，但常只在测试代码中才用到，实际代码中并没人调用。类似这样的检测函数很多，如果都public了，类的接口定义就很庞大。我一直提倡类的public函数越少越好，不必要的尽量不提供，这样调用者更容易调用。

其实不只是多个前置条件会遇到这个问题，很多添加、删除功能更是会遇到这个问题。删除一个对象的逻辑，就要求完成添加的所有准备，结果添加部分的代码被重复的测试。我的项目中，很从团队成员都干脆将所有测试写在一起，从添加到中间逻辑再到删除。结果一个测试上百行，不易读，不易修护。