相信大家在看到单元测试与集成测试这个标题时,会有很多感慨,我们无数次的在实践中提到要做单元测试、集成测试,但是大多数项目都没有做或者仅建了项目文件。这里有客观原因,已经接近交付日期了,我们没时间做白盒测试了。也有主观原因,面对业务复杂的代码我们不知道如何入手做单元测试,不如就留给黑盒测试吧。但是,当我们的代码无法进行单元测试的时候,往往就是代码开始散发出坏味道的时候。长此以往,将欠下技术债务。在实践过程中,技术债务常常会存在,关键在于何时偿还,如何偿还。
上图说明了随着时间的推移开发/维护难度的变化。
在 .NET Core 中,提供了 xUnit 、NUnit 、 MSTest 三种单元测试框架。
MSTest | UNnit | xUnit | 说明 | 提示 |
---|---|---|---|---|
[TestMethod] | [Test] | [Fact] | 标记一个测试方法 | |
[TestClass] | [TestFixture] | n/a | 标记一个 Class 为测试类,xUnit 不需要标记特性,它将查找程序集下所有 Public 的类 | |
[ExpectedException] | [ExpectedException] | Assert.Throws 或者 Record.Exception | xUnit 去掉了 ExpectedException 特性,支持 Assert.Throws | |
[TestInitialize] | [SetUp] | Constructor | 我们认为使用 [SetUp] 通常来说不好。但是,你可以实现一个无参构造器直接替换 [SetUp]。 | 有时我们会在多个测试方法中用到相同的变量,熟悉重构的我们会提取公共变量,并在构造器中初始化。但是,这里我要强调的是:在测试中,不要提取公共变量,这会破坏每个测试用例的隔离性以及单一职责原则。 |
[TestCleanup] | [TearDown] | IDisposable.Dispose | 我们认为使用 [TearDown] 通常来说不好。但是你可以实现 IDisposable.Dispose 以替换。 | [TearDown] 和 [SetUp] 通常成对出现,在 [SetUp] 中初始化一些变量,则在 [TearDown] 中销毁这些变量。 |
[ClassInitialize] | [TestFixtureSetUp] | IClassFixture< T > | 共用前置类 | 这里 IClassFixture< T > 替换了 IUseFixture< T > ,参考 |
[ClassCleanup] | [TestFixtureTearDown] | IClassFixture< T > | 共用后置类 | 同上 |
[Ignore] | [Ignore] | [Fact(Skip="reason")] | 在 [Fact] 特性中设置 Skip 参数以临时跳过测试 | |
[Timeout] | [Timeout] | [Fact(Timeout=n)] | 在 [Fact] 特性中设置一个 Timeout 参数,当允许时间太长时引起测试失败。注意,xUnit 的单位时毫秒。 | |
[DataSource] | n/a | [Theory], [XxxData] | Theory(数据驱动测试),表示执行相同代码,但具有不同输入参数的测试套件 | 这个特性可以帮助我们少写很多代码。 |
以上写了 MSTest 、UNnit 、 xUnit 的特性以及比较,可以看出 xUnit 在使用上相对其它两个框架来说提供更多的便利性。但是这里最终实现还是看个人习惯以选择。
集成测试确保应用的组件功能在包含应用的基础支持下是正确的,例如:数据库、文件系统、网络等。
总结:当我们写单元测试时,一般不会同时存在 Stub 和 Mock 两种模拟对象,当同时出现这两种对象时,表明单元测试写的不合理,或者业务写的太过庞大,同时,我们可以通过单元测试驱动业务代码重构。当需要重构时,我们应尽量完成重构,不要留下欠下过多技术债务。集成测试有自身的复杂度存在,我们不要节约时间而打破单一职责原则,否则会引发不可预期后果。为了应对业务修改,我们应该在业务修改以后,进行回归测试,回归测试主要关注被修改的业务部分,同时测试用例如果有没要可以重写,运行整个和修改业务有关的测试用例集。