首页 > 代码库 > VS 2012中消失了的Create UnitTest

VS 2012中消失了的Create UnitTest

  前言:最近正在研究一个新项目的开发工作,这个项目的要求是必须写UnitTest,对于我个人来讲是很不喜欢写UnitTest的感觉这个东西会很大程度的延误开发进度,所以之前项目的UnitTest是能不写就不写,好在作坊式的开发不在乎你写不写,功能Work就OK了,好多技术大拿都对UnitTest情有独钟,可能对于我这种码农来说无法理解其好处吧,小小抱怨也无力改变什么,只能研究研究UnitTest了。

  当我在VS12中想通过右键找到Create UnitTest这个选项的时候,我发现10中给写UnitTest带来极大方便的选项在12 13中竟然没有了(也可见我多久没写UnitTest了lol),为什么微软要将这个功能取消了呢,我个人认为是为了更好的满足TDD的开发模式,微软对于TDD的开发模式可以说是大力的支持,甚至用VS 2012的开发团队为模板来向我们这些屌丝程序员来展示什么是优雅的C#开发。那何为TDD呢,下面切入正题来说说我的一点理解。

  TDD(测试驱动开发) 是测试先行的方式,也就是说根据需求写驱动(写测试用例)。通过用例从红灯变成绿灯,使其通过了把实现的代码生成出来。通常我们的开发模式是先写完Code,然后Create UnitTest,此种方式属于测试后行。对于此两种方式,我个人感觉不能说就一定要TDD而完全否定测试后行的方式,但是TDD给我们带来的方便是今天想要谈的主题,对于两种方式的讨论,欢迎大家来辩。

  TDD此种方式最有意义的地方在于:不会因为你先去想代码实现而产生过度设计的问题,如果从实际的需求出发,你写出来的代码是最简单,最直接满足需求的方式,就不会产生过度设计的问题。在这里我同样想到了一种编程方式:结队编程,结队编程是一种将知识传播下去的方式,意思是熟悉此处逻辑的老人可以和新人一起来编写一块逻辑,通过去修改BUG,写代码,老人带着新人将这块一起做下来,包括新成员进来的时候可以通过此种方式将知识传播下去。这也是一种Code Review,两个人一起看,总比一个人看发现问题的机会要多一些,因为两个人的思路是不同的,总是一个人开发是有问题的。因此此处是想将结队编程和TDD结合的方式。一个人写Test Case,另一个人通过Test Case来写实现。下面就通过实际的例子来演示一下(演示的代码没有实际意义,只是想通过例子来展示结队编程和TDD结合)。

  比如说我们现在有一个需求求一个圆的周长,那我们需要设计两种用例,1、输入一个整数值,通过计算返回周长。2、输入一个负值,抛错。下面我需要两个人来结队通过TDD方式来实现这个Story,为了方便理解,我用大话设计模式的人物命名方式来指定两个开发人员,老鸟,菜鸟。

老鸟:我写一个类Circle,写好它的构造函数。

        private int _r;
/// <summary>
        /// TODO: Complete member initialization
        /// </summary>
        /// <param name="p">radius</param>
        public Circle(int r)
        {
            this._r = r;
        }

然后我开始写UnitTest,先创建一个UnitTest工程,然后写Test Case,写好后生成Caculate方法,设置断言,想得到正确结果。

        [TestMethod]
public
void TestPerimeter_FirstCase() { Circle worker = new Circle(1); double result = worker.Caculate(); Assert.AreEqual(result, 6.28); }

此时,我Run Test,结果是通不过,因为我的Caculate方法还没有实现,小鸟,那你来实现这个方法。

小鸟:so easy,分分钟搞定。

        private int _r;
        private readonly double _pi = 3.14 * 2;

        /// <summary>
        /// TODO: Complete member initialization
        /// </summary>
        /// <param name="p">radius</param>
        public Circle(int r)
        {
            this._r = r;
        }

        public double Caculate()
        {
            return _r * _pi;
        }

老鸟:OK,现在我们再Run Test,果然我们这个Case通过了。那我再写一个Test Case。

         [TestMethod]
        [ExpectedException(typeof(ArgumentException))]
        public void TestPerimeter_SecCase()
        {
            Circle worker = new Circle(-1);
            double result = worker.Caculate();
        }

再Run Test,又失败了。

小鸟:哦,因为没有对参数进行判断,没有考虑小于零的情况,我修改下Caculate方法的实现。

        public double Caculate()
        {
            if (_r < 0)
            {
                throw new ArgumentException();
            }
            return _r * _pi;
        }

这样两种Case就全通过了。

这个小例子就算结束了,可以看出来,我们通过TDD的方式,根据Test Case来设计代码逻辑,可以使我们的逻辑没有任何过度设计,而且这样的方式使UnitTest的代码覆盖率很高。