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

VS 2012中消失了的Create UnitTest

2024-07-04 01:00:52   223人阅读

　　前言：最近正在研究一个新项目的开发工作，这个项目的要求是必须写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的代码覆盖率很高。

 


联系
我们