.NET单元测试的艺术-3.测试代码

发表于:2018-7-31 15:50

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:Edison Chou    来源:博客园

#
Net
分享:
  一、测试层次和组织
  1.1 测试项目的两种目录结构
  (1)集成测试和单元测试在同一个项目里,但放在不同的目录和命名空间里。基础类放在单独的文件夹里。
    
  (2)集成测试和单元测试位于不同的项目中,有不同的命名空间。
     
  实践中推荐使用第二种目录结构,因为如果我们不把这两种测试分开,人们可能就不会经常地运行这些测试。既然测试都写好了,为什么人们不愿意按照需要运行它们呢?一个原因是:开发人员有可能懒得运行测试,或者没有实践运行测试。
  1.2 构建绿色安全区
  将集成测试和单元测试分开放置,其实就给团队的开发人员构建了绿色安全区,这个区只包含单元测试。
  因为集成测试的本质决定了它运行时间较长,开发人员很有可能每天运行多次单元测试,较少运行集成测试。
    
  单元测试全部通过至少可以使开发人员对代码质量比较有信心,专注于提高编码效率。而且我们应该将测试自动化,编写每日构建脚本,并借助持续集成工具帮助我们自动执行这些脚本。
  1.3 将测试类映射到被测试代码
  (1)将测试映射到项目
  创建一个测试项目,用被测试项目的名字加上后缀.UnitTests来命名。
  例如:Manulife.MyLibrary → Manulife.MyLibrary.UnitTests 和 Manulife.MyLibrary.IntegrationTests,这种方法看起来简单直观,开发人员能够从项目名称找到对应的所有测试。
  (2)将测试映射到类
  ① 每个被测试类或者被测试工作单元对应一个测试类:LogAnalyzer → LogAnalyzer.UnitTests
  ② 每个功能对应一个测试类:有一个LoginManager类,测试方法为ChangePassword(这个方法测试用例特别多,需要单独放在一个测试类里边) → 创建两个类 LoginManagerTests 和 LoginManagerTests-ChangePassword,前者只包含对ChangePassword方法的测试,后者包含该类其他所有测试。
  (3)将测试映射到具体的工作单元入口
  测试方法的命名应该有意义,这样人们可以很容易地找到所有相关的测试方法。
  这里,回归一下第一篇中提到的测试方法名称的规范,一般包含三个部分:[UnitOfWorkName]_[ScenarioUnderTest]_[ExpectedBehavior]
  1.UnitOfWorkName  被测试的方法、一组方法或者一组类
  2。Scenario  测试进行的假设条件,例如“登入失败”,“无效用户”或“密码正确”等
  3.ExpectedBehavior  在测试场景指定的条件下,你对被测试方法行为的预期
  示例:IsValidFileName_BadExtension_ReturnsFalse,IsValidFileName_EmptyName_Throws 等
  1.4 注入横切关注点
  当需要处理类似时间管理、异常或日志的横切关注点时,使用它们的地方会非常多,如果把它们实现成可注入的,产生的代码会很容易测试,但却很难阅读和理解。这里我们来看一个例子,假设应用程序使用当前时间进行写日志,相关代码如下:
  public static class TimeLogger
  {
  public static string CreateMessage(string info)
  {
  return DateTime.Now.ToShortDateString() + " " + info;
  }
  }

  为了使这段代码容易测试,如果使用之前的依赖注入技术,那么我们需要创建一个ITimeProvider接口,还必须在每个用到DateTime的地方使用到这个接口。这样做非常耗时,实际上,还有更直接的方法解决这个问题。
  Step1.创建一个名为SystemTime的定制类,在所有的产品代码里边使用这个定制类,而非标准的内建类DateTime。
   
   public class SystemTime
  {
  private static DateTime _date;
  public static void Set(DateTime custom)
  {
  _date = custom;
  }
  public static void Reset()
  {
  _date = DateTime.MinValue;
  }
  public static DateTime Now
  {
  get
  {
  // 如果设置了时间,SystemTime就返回假时间,否则返回真时间
  if (_date != DateTime.MinValue)
  {
  return _date;
  }
  return DateTime.Now;
  }
  }
  }
 

  阅读这段代码,其中有一个小技巧:SystemTime类提供一个特殊方法Set,它会修改系统中的当前时间,也就是说,每个使用这个SystemTime类的人看到的都是你指定的日期和时间。有了这样的代码,每个使用这个SystemTime类的人看到的都会是你指定的日期和时间。
  Step2.在测试项目中使用SystemTime进行测试。
  [TestFixture]
  public class TimeLoggerTests
  {
  [Test]
  public void SettingSystemTime_Always_ChangesTime()
  {
  SystemTime.Set(new DateTime(2000, 1, 1));
  string output = TimeLogger.CreateMessage("a");
  StringAssert.Contains("2000/1/1", output);
  }
  /// <summary>
  /// 在每个测试结束时重置日期
  /// </summary>
  [TearDown]
  public void AfterEachTest()
  {
  SystemTime.Reset();
  }
  }

  在测试中,我们首先假定设置一个日期,然后进行断言。并且借助TearDown方法,确保当前测试不会改变其他测试的值。
  Note : 这样做的好处就在于不用注入一大堆接口,我们所付出的代价仅仅在于在测试类中加入一个简单的[TearDown]方法,确保当前测试不会改变其他测试的值。
  1.5 使用继承使测试代码可重用
  推荐大家在测试代码中使用继承机制,通过实现基类,可以较好地展现面向对象的魔力。在实践中,一般有三种模式会被使用到:
  (1)抽象测试基础结构类模式
  /// <summary>
  /// 测试类集成模式
  /// </summary>
  [TestFixture]
  public class BaseTestsClass
  {
  /// <summary>
  /// 重构为通用可读的工具方法,由派生类使用
  /// </summary>
  /// <returns>FakeLogger</returns>
  public ILogger FakeTheLogger()
  {
  LoggingFacility.Logger = Substitute.For<ILogger>();
  return LoggingFacility.Logger;
  }
  [TearDown]
  public void ClearLogger()
  {
  // 测试之间要重置静态资源
  LoggingFacility.Logger = null;
  }
  }
  [TestFixture]
  public class LogAnalyzerTests : BaseTestsClass
  {
  [Test]
  public void Analyze_EmptyFile_ThrowsException()
  {
  // 调用基类的辅助方法
  FakeTheLogger();
  LogAnalyzer analyzer = new LogAnalyzer();
  analyzer.Analyze("myemptyfile.txt");
  // 测试方法的其余部分
  }
  }

  使用此模式要注意继承最好不要超过一层,如果继承层数过多,不仅可读性急剧下降,编译也很容易出错。
  (2)测试类类模板模式
上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。
31/3123>
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号