使用MS Test作单元测试

声明：本篇博客翻译自：http://www.c-sharpcorner.com/article/unit-testing-with-ms-tests-in-c-sharp/

写在翻译以前：

依然清晰的记得刚工做的第一个项目中，在完成一个功能模块开发后，师傅让我把代码作一下单元测试。当时一脸“懵懂”。内心的疑惑油然而生，测试不该该是测试人员作的吗？而后就写了一些测试用例把功能简单过了一遍。过了几天后，师傅问我单元测试完成了吗？我很自信的告诉师傅搞定了。师傅让我把单元测试的代码提交到服务器上，他想Review一下！我更加疑惑了，对师傅说，单元测试还要写代码呀？:(

前言：

不少初级开发工程师都会有这样的困惑：谁应该来作单元测试。单元测试应该是由开发者来完成的。

单元测试：

经过一些代码来测试一个方法/函数的行为。

为何须要单元测试：

• 一般状况下，一个软件项目会长期运行/维护/更新，这个时间至少也会有5年的时间；
• 在这期间，维护这个程序很是重要；
• 任何一个代码的改动都有可能会影响程序的其余功能模块；
• 所以在更新程序之间，会须要作大量的回归测试(Regression Testing)，这将花费测试工程师大量的时间。

想象一下若是代码修改须要很是频繁，那么花费在回归测试上的精力会很是多，一样的，也会有很大的概率捕捉到功能回退(修改缺陷)的问题。

回归测试：

回归测试是确保当增长了新的修改后，老的功能依旧能够正常使用。

单元测试：

• 单元测试将会最小化回归测试的范围：
• 每个方法/函数都会被一系列的测试方法覆盖，这些测试方法将测试真实方法的功能；
• 测试方法会检查下面的场景/行为：
  • 成功/正常流程
  • 失败
  • 异常/错误处理
• 一个方法可能须要多个测试方法，这取决于测试方法的复杂度；
• 在代码交付以前，开发者须要确保全部的测试方法均运行经过。

TDD:

 

在写产品代码以前先写单元测试代码，而后使用产品代码来填充/覆盖测试代码。最终使测试代码都运行经过。

编写测试用例：

在C#中有2个测试框架

• MS Test
• NUnit

咱们使用AAA模式来编写单元测试

1. 安排因此必须的前置条件和输入；
2. 在测试代码中操做被测试对象和方法；
3. 断言期待的结果；

右击解决方案浏览器，选择Unit Test Project并添加：

Employee类：

    public class Employee
    {
        public string GetName(string firstName, string lastName)
        {
            return string.Concat(firstName, " ", lastName);
        }
    }

 单元测试类：

    [TestClass]
    public class EmpoyeeFunctionalTest
    {
        [TestMethod]
        public void GetNameTest()
        {
            // Arrange
            Employee employee = new Employee();
            string firstName = "Jimmy";
            string lastName = "Yang";
            string expacted = "Jimmy Yang";
            string actual = string.Empty;

            // Act
            actual = employee.GetName(firstName, lastName);

            // Assert
            Assert.AreEqual(expacted, actual);
        }
    }

 但愿上述内容可以帮助你对单元测试有一个概念性的认识。

感谢您的阅读！翻译的不到位之处还望指正。谢谢~