• 14
  • 14
分享
  • 【译】如何写一手漂亮的测试代码
  • Tynam 2021-02-07 14:44:37 字数 2697 阅读 1619 收藏 14

在编写 Junit 测试时,我采用了同一套格式。如此,对于测试用例我就可以遵循这套格式进行编写和阅读,使所有的测试都整体划一。这种格式模板可以帮助我更快的编写测试,提高工作效率。今天我就与大家分享我的这套格式模板。

(译者评:与我在测试建设原则中提出的继承原则相同,都是在进行一项测试工作之前,将公共的进行提取,统一格式模板,然后在以后的测试活动中都继承这套模板开展。)

文件格式

首先,在项目的测试包下新建一个测试文件/测试类,并且创建测试方法。在编写测试文件/测试类时,所有的测试文件/测试类都以 Test 结束,这样会容易理解其是一个测试文件/测试类,也方便后期维护时查看,编辑。例如一个名字为 SomeService 的类就会有一个名为 SomeServiceTest 对应的测试类。

(译者评:这是一个很好的习惯,在项目测试中可以考虑作为一种规定。就是开发在程序中写了一个 SomeService 类,那么在测试 SomeService 类时文件名就需要是 SomeServiceTest,以 类名 + Test 的形式进行命名测试类。)

然后,给测试取一个容易识别,区分,好听的名字,笔者个人比较喜欢省略单词 test,因为就是在测试类中进行的,继续在名字中添加 test 看起来就有点累赘。对于测试名字需要从名字中读取出所测的内容,这样我们就可以更好的对每一个测试进行区分。

public SomeServiceTest{
   @Test
   public void sortByPopularVoteDesc() {

   }
   @Test
   public void sortByPopularVoteAsc() {

   }}

(译者评:对于测试名,取一个易于理解的还是比较支持的,见名知意。但对于省略单词 test,译者理解的是一般情况下可以省略,但是某些必要的场景还是希望添加。)

大纲

接下来,笔者会在测试方法中写入一些模板,这种模板是我在写所有测试中都会使用的模板。首先在测试方法中设置了一个预置条件 setup,然后对方法进行测试 test,最后进行断言 assert/validate,通过断言来确保与期望结果一致。

public TestClass{
   @Test
   public void sortByPopularVote() {
     // setup     
      // test      
      // assert/validate    }}

上面代码中部分内容的含义:

  • setup: 测试预制条件写的地方。

  • test: 对方法进行测试地方。

  • assert/validate: 此处写断言。

(译者评:作者在此写的并不是很全。有准备条件,但是没有销毁条件。我们都知道,在进行自动化测试时非常重要的一个步骤就是数据复原。如果测试后数据没有复原,将会影响一次的执行。所以在上面三个过程后,还应该存在一个销毁条件 teardown,虽然可能 teardown 不是一个必须项。所以一共应该有四个步骤,setup、test、assert/validate、teardown。)

(译者评:上面写的范围有点小。不仅在测试类中需要有这样的设置,在测试类层面、测试文件层面也需要 setup、test、assert/validate、teardown 四个步骤。)

预制条件

最后,我简单的填充了一下空白。如果预置条件和所有其他测试的预制条件相似,笔者会将此逻辑抽象为 @Before 函数。每个测试之前都会执行此函数。如果多个测试,但不是所有测试,之间需要设置一个预制条件,那么就将其设置为一个私有函数进行封装。对于一般的测试,使用这两种方法设置预制条件都可以提高代码的复用性。如果需要改变测试的预制条件,那么只需要对一个地方进行改变便可以达到目的。在进行测试重构时这将是非常实用的。

public TestClass{
 private List<SortableObj> expected;
 private final SortableObj first = new SortableObj();
 private final SortableObj second = new SortableObj();
 private final SortableObj third = new SortableObj();
 private final SortableObj fourth = new SortableObj();

  @Before
  public void before{
    // some decoration on objects     
    // ...     expected = Arrays.asList(first, second, third, fourth);
  }

   @Test
   public void sortByPopularVote() {
     // setup      List<SortableObj> actual = Arrays.asList(fourth, third, first, second);
     // test      Collections.sort(actual);
     // assert/validate      assertThat(actual).isEqualTo(expected);
   }}

测试命名

在进行预期结果和实际结果命名时,使用 expected 和 actual 是非常有效的。 使用这两个关键字写断言也非常易于阅读。actual 是实际结果,expected 是预期结果,使用这两个结果进行对比。

  • expected :这是预期结果,即是希望的结果是什么。预期结果可能有多条,在写的时候请按照一定的顺序进行。

  • actual :测试执行后,实际输出的结果。 命名是对一个事物进行设计或选择的名字,特别是在科学或其他学科中。在软件开发和测试中,涉及到 API、响应结果、变量、函数、文档名称。 

(译者评:四个字,见名知意。)


结论

使用这个格式模板进行测试,可以提高测试效率,使代码更易维护。

(译者评:全文所说的文件格式、测试顺序、断言命名、预期结果排序还是值的学习的,特别对于没有经历过痛苦的维护代码的人员来说非常又必要。就是内容太少,总结的太少。)



原文:https://dev.to/ninan_phillip/how-to-write-great-tests-4719


  • 【留下美好印记】
    赞赏支持
登录 后发表评论
+ 关注

热门文章

    最新讲堂

      • 推荐阅读
      • 换一换
          • 目前APP同硬件模块通信的方式主要有几种模式: 蓝牙连接模式、WiFi 连接模式(Socket 或 HTTP server)、DLNA 音视频共享 (iOS端还可使用AirPlay)。最近 点个赞科技项目中测试了 A PP与外设 通 过 蓝牙方式 实现 硬件 连 接 的功能,对相关的开发实现和测试方法进行一些整理, 在此分享给大家。1、蓝牙基础知识iOS平台下蓝牙开发可以使用 MFI(ExternalAccessory 框架)或 BLE (CoreBluetooth 框架) 进行,但实际开发中基本都使用 CoreBluetooth 框架,因为它功能更强大,支持蓝牙4.0标准;蓝牙4.0 BLE...
            13 13 1469
            分享
          •   做软件测试的人,往往会有这样的想法:由于软件的复杂导致了测试的复杂,所以不能指望培训能给我们很多工作中的实际指导。偏重理论是肯定的,但并非没有意义,虽然理论同样可以从相关的文献资料上得到。因为测试时从来不希望检测被测系统所有可能的输入、路径和状态,那么应该选择什么?什么时候应该停止测试?什么时候应该暂停测试?怎样编写一个测试包,它可以检测足够多的消息和状态的组合来说明没有失败的操作,但是从实用性来说它又足够的小?  测试提出了许多基本的但却令人困惑的难题,带着这些问题,所以参加了几次实用软件测试培训。  一、软件测试员的目标是尽可能早地找出软件缺陷,并确保其得以关闭  仔细思考后,我觉得此...
            0 0 925
            分享
          •   点击链接参加测试行业调查问卷,提交成功之后免费获得独家测试资料,链接:http://vote.51testing.com/  机器学习、人工智能各类KNN算法层出不穷,DBSCAN具有强代表性,它是一个基于密度的聚类算法,最大的优点是能够把高密度区域划分为簇,能够在高噪声的条件下实现对目标的精准识别,但该算法当前已远不能满足人们对于高效率、高精准度的算法要求,由此FDBSCAN算法应运而生。  01  FDBSCAN聚类算法在KD-树的加持下,时间复杂度达到了O(nlogn),目标识别效率已指数级别上升。  02  Kd-树:它是一种树形结构,主要应用于多维空间关键数据的搜索。由于他的增加...
            0 0 790
            分享
          • 推荐标签:软件测试技术测试用例测试方法在信息技术外包世界,对一个公司拥有它的应用程序和被其他人开发或者维护的框架是普遍的。当销售商完成这个生意,一个普通的实验是把测试过渡活动当成是一个整体。你如何设计一个传统实验的可接受标准以至于它可测试并且被清晰沟通?作为测试,我们通常讨论当一个应用程序被创建时如何接近测试并且被在我们自己公司内的团队维护,但是我们很少讨论当从一个外包供应商到另一个变化时发生了什么。在信息技术外包的世界,对一个公司拥有它的被其他人开发和维护的应用程序和架构是普遍的。当销售商完成这笔生意,有合同涉及组建管理,实时服务水平,关于发布内容的委员会,等等。一个普通的合同部分是测试交换...
            0 0 1870
            分享
          •   1. 场景法(流程图法)  1.1 基本概念理论  场景法就是模拟用户操作软件时的场景,主要用于测试多个功能之间的组合使用情况。  场景法通常在集成测试、系统测试和验收测试阶段使用。  使用场景法设计测试用可以参照下述步骤:  ·需求分析  · 根据需求绘制流程图,比如网购的流程  · 根据流程图设计测试用例,每一条流程路径就是一条测试用例。  在绘制流程图时,有几个常用的通用符号:  · 流程开始或结束 - 椭圆形  · 方向或者路径 - 箭头  · 处理或者操作 - 长方形  · 判断 - 菱形  · 输入或者输出 ...
            0 0 1191
            分享
      • 51testing软件测试圈微信