毋庸置疑,程序的单元测试于人于己都是有益的,毕竟我们不可能永远开发新的软件而不对现有的程序进行维护更改。
大概念说得太多了,我知道的单元测试具体做法有几种:
1. 将测试代码与工程代码混在一起,做到随测随写。
好处是间距进,查阅方便。特别针对提供API给客户端调用的同学,当写文档或者查阅代码具体调用时,可以直接拷贝测试方法中的代码。
缺点是将与程序代码与无关的测试代码混合在一起,导致assembly体积变大,项目工程结构变得不清晰,当程序将assembly 加载至内存中时,占地方,有同我一样洁癖的同学慎用。
2. 单独建立单元测试工程,根据每个代码文件,对应相应的测试用例文件,例如代码:a.cs 单元测试:a_test.cs
好处及坏处同第一种方法所述正好相反,我个人更喜欢这种方法,故在此讨论一下如何用代码实现这种方法的测试用例。
单元测试需要达到一定的测试覆盖率才变得有意义,public的方法就不说了,而我们如何调用需测试代码中的private的方法呢? 当然,我们可以用反射的方法,建立被测对象的实例,进行方法执行。那么internal的方法吗,也要用反射这样麻烦吗? 其实我们可以说不,窍门就在于一个attribute [assembly: InternalsVisibleTo(”单元测试名称assembly")]
请参考以下示例:
建立一个代码工程,里边放入具体的执行代码:
1: using System;
2: using System.Runtime.CompilerServices;
3:
4: [assembly: InternalsVisibleTo("ActuallyCode_UnitTest")]
5:
6: namespace ActuallyCode
7: {
8: internal class RunningCode
9: {
10: public void TestCode()
11: {
12: Console.WriteLine("I am running.");
13: }
14: }
15: }
然后我们建立一个单元测试工程,并将执行代码引入进来,里边放入需执行的测试代码:
1: using System;
2: using Microsoft.VisualStudio.TestTools.UnitTesting;
3: using ActuallyCode;
4:
5: namespace ActuallyCode_UnitTest
6: {
7: [TestClass]
8: public class UnitTestForActuallyCode
9: {
10: [TestMethod]
11: public void TestCodeMethod()
12: {
13: RunningCode foo = new RunningCode();
14: foo.TestCode();
15: }
16: }
17: }