VS2013 生成测试单元, 如何自动生成部分代码

[zhouandke]

对于一个方法

        public int Sum(int a, int b)
        {
            return a + b;
        }

在VS 2010 使用 创建单元测试 会自动生成下面代码

        [TestMethod()]
        public void SumTest()
        {
            Program target = new Program(); // TODO: 初始化为适当的值
            int a = 0; // TODO: 初始化为适当的值
            int b = 0; // TODO: 初始化为适当的值
            int expected = 0; // TODO: 初始化为适当的值
            int actual;
            actual = target.Sum(a, b);
            Assert.AreEqual(expected, actual);
        }

VS 2010自动生成了一系列初始化值, 包括
创建类Program的实例
对参数 a, b 创建初始值
基本的断言

但是在 VS 2013 使用 Unit Test Generator 却没有以上初始化代码

        [TestMethod()]
        public void SumTest()
        {
            Assert.Fail();
        }

请问:
1. 有什么方法能让VS 2013 的Unit Test Generator 自动生成VS 2010 那样的基本初始化代码段呢?

2. 再衍生一个我想了解的问题, 假如还有一个参数是string c, 通常我们都会判断是否是null, 是否是string.Empty, 并抛出异常; 那么有没有工具可以生成N个测试方法, 里面就包括了输入参数c 分别是null 和 string.Emtpy 的情况呢?

[以专业开发人员为伍]

如果你就是写这类刚学几天编程才写的代码，可能你希望vs自动给产生一堆那样的“测试用例”。但是假设你稍微写点正规的软件，如果本来是100个测试用例就可以了，而vs自动给你产生了10000个测试用例，你愿意把这10000个测试用例都跑一遍吗？ 而且，vs就算是给你产生了10000个测试用例，估计其中也没有几个是真正恰当的。例如我们需要一个测试用例

[TestCase("对图片base64然后zip", "2013.7.23 14:12", "fqs", RiskyBoos = false)]
public static void t24()
{
    var file = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "datas", "lena-256x256.jpg");
    var data = File.ReadAllBytes(file);
    var source = new MemoryStream(data);
    var result = new MemoryStream();
    source.GZipCompress(result);
    var ds = result.ToArray();
    Debug.Assert(ds.Length > 10000 && ds.Length < data.Length);
}

或者一个测试用例

[TestCase("测试mongodb建立blog集合", "2011.11.13 6:59", "westwuwei", RiskyBoos = false)]
public static void t4()
{
    var db = Common.CommonExtensions.Mongo("test");
    var bag = db["blog"];
    bag.InsertBatch<Blog>(new Blog[] { 
        new Blog { title = "My Blog Post.", content = "Here's my blog post.", date = DateTime.Now },
        new Blog{ title="何处不插电", content="一门关于插电的学问", date= DateTime.UtcNow }
    });
    Debug.Assert(bag.Find(Query.Null).Count() >= 2);
    bag.Update(Query.EQ("title", "My Blog Post."), Update.Set("comments", new BsonArray()));
    bag.Remove(Query.EQ("title", "My Blog Post."));
}

你可以看到，vs无法创建这类测试用例，这需要程序员动脑子。这种测试用例也许需要你写300个，但是假设vs给你胡乱写上30万个，能顶上你写300个吗？ 显然，vs产生的那些，都是哄小孩子的代码。

[以专业开发人员为伍]

其实我们也可以稍微扩展到传统的手工“测试理论”上，许多理论说的所谓的“覆盖”都是哄小孩子的，在实践中根本不可能劳民伤财去进行低级地“覆盖”，尤其是根本不知道测试用例能够测到哪里而胡乱要求“测试覆盖率达到90%以上”的要求都是是自欺欺人的。许多人都写那些骗自己领导的测试用例，目的只是为了保证“测试覆盖率”，而这些测试用例往往都是胡乱按照代码来拼凑的。 真正的测试要分析业务流程内部机制才能写出来，而垃圾测试往往是随便按照代码的皮毛（形式）来胡写。

[Poopaye]

看这代码是你的步骤有问题吧，生成的时候vs没报错吗？

[七步777]

不必太强求，能帮你自动生成的都是一些比较简单的，自己补充下就好了，还可以熟悉。 好比新建工程帮你生成的program.cs 假设这个时候你需要写一个登陆的程序，明显这个生成的就不太合要求，需要去里面改改。 另外没有一个工具可以帮你测试所有程序，不然要软件测试工程师干嘛？

[zhouandke]

引用 5 楼 u013421223 的回复:

不必太强求，能帮你自动生成的都是一些比较简单的，自己补充下就好了，还可以熟悉。 好比新建工程帮你生成的program.cs 假设这个时候你需要写一个登陆的程序，明显这个生成的就不太合要求，需要去里面改改。 另外没有一个工具可以帮你测试所有程序，不然要软件测试工程师干嘛？

谢谢, 其实第二个问题只是随便问问, 我也知道意义不大 我主要还是想知道第一个问题有没有解决办法 按理说吧, 每天已经敲N多代码了, 再多写那么几行初始化赋值也是不值一提的事情, 可是我就是懒, 不想重复的敲那么几行, 如果工具能生成那么几行, 不是挺好的么

[zhouandke]

引用 4 楼 shingoscar 的回复:

看这代码是你的步骤有问题吧，生成的时候vs没报错吗？

嗯, 简化了一点VS生成的代码 举的例子很简单, 主要是怕自己说不清除第一个问题

[zhouandke]

引用 2 楼 sp1234 的回复:

如果你就是写这类刚学几天编程才写的代码，可能你希望vs自动给产生一堆那样的“测试用例”。但是假设你稍微写点正规的软件，如果本来是100个测试用例就可以了，而vs自动给你产生了10000个测试用例，你愿意把这10000个测试用例都跑一遍吗？

嗯, 是的, 例子确实too young, too simple, 还望忽视 其实第二个问题只是随便问问, 我也知道意义不大 我主要还是想知道第一个问题有没有解决办法 按理说吧, 每天已经敲N多代码了, 再多写那么几行初始化赋值也是不值一提的事情 可是我就是懒, 不想重复的敲那么几行, 如果工具能自动生成那么几行, 不挺好的么 当然有这样的工具更好, 没有的话, 自己敲呗 唉, 微软不在 Unit Test Generator 加入自动生成初始化赋值的代码, 肯定是有原因的, 我能猜到的就是: 生成相对复杂的样例, 会给开发人员添乱

[zhouandke]

自己顶顶，是不是分太少了？

[zhouandke1]

我还是总结一下自己的理解吧, 想说的主要还是第一个问题, 第二个问题本来就是打酱油的 我之所以提第一个问题, 主要的原因还是没有将测试运用到实际生产环境中 我举的例子 public int Sum(int a, int b){...}; 如果能有VS 2010 自动生成的初始化代码, 确实也不错 但实际工作中, 很少有这样简单的方法, 绝大多数都是类似 public void SaveDataSetToExcel(DataSet ds, string excelPath){...}; 测试用例, 需要自己构造较为复杂DataSet, 还要有一个excel文件与方法生成的excel进行对比, 反正就是代码很多 如果用VS 2010 自动生成测试代码呢, 大概是这样子 DataSet ds=new DataSet(); string excelPath=""; Assert.Fail(); 如果开发人员在以上代码中修改并加入自己的代码, 反倒比较麻烦, 很有可能直接删掉, 顺着自己的思路一路写下去 所以, 我猜测, 微软不自动生成初始化代码, 大概就是这个原因吧