求高手指教如何实现单元测试自动化

[cool19880114]

是关于.net的单元测试自动化

[CGabriel]

你要哪个级别的自动化先。。。是不是定时 build 一下 solution， 然后自动 Run 所有的 Unit Test?

如果是那样的话，有很多的工具，例如 CI build.

[以专业开发人员为伍]

比如说你写一个“求阶乘”的函数fa，测试可以这样写

public void test1()
{
    var r=fa(0);
    Debug.Assert(r==1);
    var r=fa(1);
    Debug.Assert(r==1);
    var r=fa(2);
    Debug.Assert(r==2);
    var r=fa(3);
    Debug.Assert(r==6);
}

public void test2()
{
    var r=fa(5);
    Debug.Assert(r==120);
}

而你的fa可以首先这样实现

int fa(int x)
{
    return 1;
}

这就会让第一个测试的前两个断言通过。然后第三个断言出错，于是可以修改为

int fa(int x)
{
    if(x<=1)
        return 1;
    else
        return 2;
}

于是第三个断言通过。可是第四个断言又出错，于是可以再重构为

int fa(int x)
{
    if(x<=1)
        return 1;
    else  if(x==2) 
        return 2;
    else
        return 6;
}

......测试驱动首要的是保证尽可能简单设计。


对于工程应用，顺便贴上我在 javaeye 上的回复，供你参考：


编程人员基于传统的单元测试的书本知识来写测试是作用很有限的。当你花很长时间（比如2天）写下功能代码，然后再考虑写单元测试，这时候写出的所谓单元测试往往是限于你的编程思路中，其实是重复无用的东西。传统的测试只好纠缠于所谓覆盖率问题，让人难以自拔。

这是因为传统的单元测试思路的所谓“单元”，纠缠于个别功能代码，而不是反映需求。

敏捷开发强调是先写测试，用测试来驱动出设计思路，测试代码是针对设计而不是针对你的实现代码！这是非常关键的。由于是比较高层次的测试思路（即根本不考虑你的实现代码），当你写30个纯粹为了驱动出设计才写的测试，并且每10分钟之内就回归一次（每一次自动随机产生测试数据），那么这些测试之间相互牵制就会发现大量深层次bug。特别是，要打乱测试顺序、并且可能的话开100个线程并发测试，可以发现大量深层次bug。

核心的观念是：1.测试不是用来证明你的实现代码的，测试应该驱动设计的。2. 测试应该每1~10分钟进行一次（你可以选择大部分时间仅执行最近7天的测试，但是每天也要至少进行5次全面回归测试）。3. 在有任何编程想法前都坚持先写测试然后才实现，而不是相反。4. 你编程每一个1个小时都应该写下一个测试，而不是2、3天才写一个测试。5.一个项目的测试驱动必须达到一定强度，也许100也许3000，总之不会很少。

真正的测试驱动开发，轻松、自然、有趣，你会有勇气去修改自己的代码，有勇气让别人随时修改你自己的代码，有勇气随时（闲时）重构系统结构。看似摸着石头过河，实则永远追求统一。你不再盲目纠缠于理论，不再简单地靠过分纠缠理论的是是非非来“保证”你的代码的正确性。

不但对于功能代码，对于GUI也要自动化测试。一个基本的原则是：如果你的代码注释掉了之后仍然可以让自动测试程序通过，那么就说明这些未经测试驱动的代码就是有毒的代码早就应该删掉。

要想进行测试驱动开发，首先要抛开传统的单元测试观念。

[以专业开发人员为伍]

sorry，代码中多写了三个 var，请删除。

我从来不用vs的所谓单元测试工具，它华而不实，缺乏有用的东西。实际上写测试代码很容易，你创建一个应用程序，引入你要测试的工程，然后就直接写一个一个短小的test小程序就可以了。然后你稍微花上点时间，写个反射来自动收集这些短小的test程序的小程序，或者不反射而是手工在一个 Action[] 数组中去声明也行，例如

static Main()
{
    Action[] tests=Action[]{test1,test2,Class1.test1};
    StartTest(tests);
}

自己写一个StartTest程序从测试程序集合中随机挑选一个Action执行，例如

for(var i=0;i<100,i++)
    tests[Rnd.Next(tests.Count)]();

这不就驱动起来了嘛！

[以专业开发人员为伍]

哦，又少写了一个 new，哈哈！

[CGabriel]

呃。。可能sp1234大的自动化测试的定义跟我有所变差， sp1234大提到的是 TDD 的概念。

而在我眼里，测试自动化则是：一旦有新的代码 check in 或者到了特定的时间点（通常都是下班后，搞个 nightly build 出来），有一个工具会跑到源代码服务器上，把整个 solution check out 下来，然后 build 一次，接着自动启用 NUnit 或者 MS Unit Test，把已经写好的 Unit Test 跑一遍，最后丢份报告出来。

明天早上大家一上班，就知道昨天干的活有没有问题了。

[缪军]

旁听ing

[APP开发王]

友情帮顶下！顺便学习学习！