使用MS Test做单元测试
声明:本篇博客翻译自:http://www.c-sharpcorner.com/article/unit-testing-with-ms-tests-in-c-sharp/
写在翻译之前:
依然清晰的记得刚工作的第一个项目中,在完成一个功能模块开发后,师傅让我把代码做一下单元测试。当时一脸“懵懂”。心里的疑惑油然而生,测试不应该是测试人员做的吗?然后就写了一些测试用例把功能简单过了一遍。过了几天后,师傅问我单元测试完成了吗?我很自信的告诉师傅搞定了。师傅让我把单元测试的代码提交到服务器上,他想Review一下!我更加疑惑了,对师傅说,单元测试还要写代码呀?:(
前言:
很多初级开发工程师都会有这样的困惑:谁应该来做单元测试。单元测试应该是由开发者来完成的。
单元测试:
通过一些代码来测试一个方法/函数的行为。
为什么需要单元测试:
- 通常情况下,一个软件项目会长期运行/维护/更新,这个时间至少也会有5年的时间;
- 在这期间,维护这个程序非常重要;
- 任何一个代码的改动都有可能会影响程序的其他功能模块;
- 因此在更新程序之间,会需要做大量的回归测试(Regression Testing),这将花费测试工程师大量的时间。
想象一下如果代码修改需要非常频繁,那么花费在回归测试上的精力会非常多,同样的,也会有很大的几率捕捉到功能回退(修改缺陷)的问题。
回归测试:
回归测试是确保当增加了新的修改后,老的功能依旧可以正常使用。
单元测试:
- 单元测试将会最小化回归测试的范围:
- 每一个方法/函数都会被一系列的测试方法覆盖,这些测试方法将测试真实方法的功能;
- 测试方法会检查下面的场景/行为:
- 成功/正常流程
- 失败
- 异常/错误处理
- 一个方法可能需要多个测试方法,这取决于测试方法的复杂度;
- 在代码交付之前,开发者需要确保所有的测试方法均运行通过。
TDD:
在写产品代码之前先写单元测试代码,然后使用产品代码来填充/覆盖测试代码。最终使测试代码都运行通过。
编写测试用例:
在C#中有2个测试框架
我们使用AAA模式来编写单元测试
- 安排所以必须的前置条件和输入;
- 在测试代码中操作被测试对象和方法;
- 断言期待的结果;
右击解决方案浏览器,选择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); } }
希望上述内容能够帮助你对单元测试有一个概念性的认识。
感谢您的阅读!翻译的不到位之处还望指正。谢谢~
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。