编写更好的单元测试的技巧[已关闭]

2. 测试尽可能小的东西。然后测试下一个最小的东西。
3. 测试所有合理的输入和输出范围。IOW:如果你的方法返回布尔值,一定要测试false和true的返回值。对于int?-1,0,1,n,n+1(通过数学归纳法证明)。不要忘记检查所有异常(假设是Java)。 4a。先写一个抽象接口。 4b。第二次写你的测试。 4c。最后写下你的实现。
4. 使用依赖注入。(对于Java:Guice——据说更好,Spring——可能已经足够好了)
5. 用mockito这样的好工具包来模拟你的“单元”合作者(再次假设是Java)。
6. 谷歌很多。
7. 继续努力。(我花了两年时间——除了谷歌,没有太多帮助——才开始“理解”它。)
9. 冲洗,重复。..

编写测试 之前

如果你有时间,那么你甚至可以考虑编写测试,忘记一周,然后编写实际的代码。通过这种方式,您已经远离了问题,现在可以更清楚地看到问题。如果任务来自外部或内部来源,我们的大脑处理任务的方式会有所不同,而这种中断使其成为外部来源。

在我目前的项目中,我们使用一个小生成工具为各种实体和访问器生成骨架单元测试,它提供了一个相当不错的 一致的 该方法适用于需要测试的每个模块化工作单元,并为开发人员提供了一个测试其实现的好地方(即,当默认添加其余实体和其他依赖项时,会添加单元测试类)。

读一本像这样的书 The Art of Unit Testing 肯定会有所帮助。

就政策而言 Kent Beck's answer 关于SO,特别是:

尽可能少地测试以达到给定的置信水平

为代码中棘手的部分编写实用的单元测试,不要忘记这样一个事实,即重要的是你正在测试的程序,而不是单元测试。

我有一个ruby脚本,它为不是用TDD构建的“棕色”代码生成测试存根。它编写我的构建脚本,设置includes/using s,并编写一个setup/teadown来实例化存根中的测试类。有助于从一个一致的起点开始,而不会在我破解黑暗时代编写的代码时感到枯燥乏味。

我发现一种非常有用的做法是制作测试套件 同构 对于正在测试的代码。这意味着测试按照它们正在测试的代码行的顺序排列。这使得很容易获取一段代码和该代码的测试套件,并排查看它们,并逐步检查每一行代码以验证是否有适当的测试。我还发现,仅仅像这样强制同构的行为就迫使我仔细思考正在测试的代码,例如确保代码中的所有可能分支都经过测试,或者所有循环条件都经过测试。

例如,给定这样的代码:

void MyClass::UpdateCacheInfo(
    CacheInfo *info)
{
    if (mCacheInfo == info) {
        return;
    }
    info->incrRefCount();
    mCacheInfo->decrRefCount();
    mCacheInfo = info
}

此功能的测试套件将按顺序进行以下测试:

test UpdateCacheInfo_identical_info
test UpdateCacheInfo_increment_new_info_ref_count
test UpdateCacheInfo_decrement_old_info_ref_count
test UpdateCacheInfo_update_mCacheInfo