我的单元测试之总结

单元测试

版权声明:本文为博主原创文章,未经博主允许不得转载。

以下关于单元测试的总结,是基于目前工作的内容进行的汇总,包括了单元测试的定义,单元测试assertion语句,单元测试的框架以及实践中的注意事项等。其中【***】为解释说明。在此推荐几本有关单元测试的书籍供参考。《单元测试的艺术》《单元测试之道junit(Java版)》《单元测试之道Nunit(C#版)》。

Overview

一个UT当中,包括了准备数据,释放资源,执行要验证的那段逻辑代码,以及结果的验证等。

准备数据:包括setUpTestCase 和setUp【setUpTestCase different from setup, setUpTestCase is Sets up test environment for test case, it should be run only one time, setup should be run first when run every test case.】setUpTestCase的数据准备是对一个UT中的所有test case所做的数据准备,这个在运行UT时系统仅运行一次,而对于setUp,每跑一个test case,都会跑一次setUp。

释放资源:包括tearDownTestCase和tearDown【When finished test case, release source, tearDownTestCase is deferent from teardown, one for all test case, one for every test case.】,一个是对整个UT运行结束后释放资源,一个是每跑完一个test case,立即释放资源,这样做的好处是防止了数据不干净产生的结果验证不正确的困扰。

执行要验证的那段逻辑代码:则我们需要写单元测试的部分是希望在系统薄弱的地方找出更多的bug,所以,开发的代码中没有逻辑的代码,我们不需要花时间去验证。应该把时间和精力放在可能出现问题的地方。

结果的验证:在准备数据的时候,我们其实已经知道了代码运行之后的结果是什么,我们只需要知道它是否跟我们的期望是一致的,跟产品的功能是一致的。还有不要为了测试而测试,case跑通了不重要,重要的是你是不是测到点上了。

准备不同的数据去尽可能的验证所有的分支,保证测试的覆盖率。

综上所述,一个UT的执行顺序是:setUpTestCase ----> setup----> testCase1---->teardown----> setup----> testCase2---->teardown ...----> tearDownTestCase .

基础知识铺垫:

一、什么是UT:

UT 指单元测试,是为了证明某段代码行为确实和开发所期望的是一致的,验证代码的功能及操作特性,换句话说就是用一段代码验证另一端代码的逻辑正确与否。

二、UT中的Assertion语句:

①验证实际值和期望值是否一致:

assertEquals(expected, actual, string message);

asserNotEquals(expected, actual, string message);

②验证一个给定的object是否为空或者非空:

assertNull(Object object, string message);

assertNotNull(Object object, string message);

③验证期望值和实际值所引用的对象是否为相同的对象:

assertSame(expected, actual, string message);

assertNotSame(expected, actual, string message);

④验证在条件下是否为ture或false:

assertTure(anytype condition, string message);

assertFalse(anytype condition, string message);

⑤验证期望的object和实际的object是否为相等的。

assertObjectEquals(expected, actual, string message);

assertNotObjectEquals(expected, actual, string message);

⑥Checks whether two values are equal with regard to a delta.

assertRealEquals(expected, actual, delta, string message);

⑦Checks whether two UTC date time values are equal with regard to a delta.

assertUTCDateTimeEquals(expected, actual, string message, delta)

三、Attribute we used

Use [SysTestGranularityAttribute(SysTestGranularity::Component)]? ? attribute to mark intentional component tests.
Use [SysTestGranularityAttribute(SysTestGranularity::Integration)]? ? attribute to mark intentional Integration tests.
Use [SysTestGranularityAttribute(SysTestGranularity::BusinessCycle)]? ? attribute to mark intentional Business Cycle tests.

[SysTestInactiveTest] attribute to ignore the case.

[SysTestMethod] attribute for each test, it can be make case can be run.

[SysTestCheckInTest] attribute for each test or test class.

In SetupTestCase for all tests in the class, add attribute to the class :

#isoCountryRegionCodes

SysTestCaseCountryRegionDependency(#isoTH)] to set country region code for test case.

[SysTestTarget(classstr(CustVendTransData), UtilElementType::Class) attribute to specify the target element for code coverage.

[SysProductAreaAttribute("***")] attribute to define the product area the class belongs to.

四、Framework of UT

[attribute]

class ClassName extends class

{

Declare variable;【Use const to declare variable.】

/// <summary>

/// Sets up test environment for test case.

/// </summary>

Public void setUpTestCase()

{

ttsbegin;   【Begin transaction, and commit transaction or abort transaction, to prevent data is not clean】

Prepare Data;

   ttscommit;

}

public void tearDownTestCase()

{

infolog.clear(0);

  testData.tearDown();

testCompany.tearDown();

super();

}

/// <summary>

/// Sets up test.

/// </summary>

public void setUp()

{

  }

public void tearDown()

{

super();

}

/// <summary>

/// Comments.

/// </summary>

[SysTestMethod]

public void testcase1()    【testcase1 should be use a meaningful name, and lower first letter.】

{

// Arrange

[Setup the test case]

// Act

[Act on the system under test/unit]

// Assert

[Validate the result]

}

/// <summary>

/// Comments.      【Xml document should be add to every test method, capital letters and summary should be a meaningful sentence.

/// </summary>

[SysTestMethod]

public void testcase2()

{

// Arrange

[Setup the test case]

// Act

[Act on the system under test/unit]

// Assert

[Validate the result]

}

}

五、Tips of UT

  1. Tests should include three comments separating sections of the code:

      // Arrange

       [Setup the test case]

      // Act

[Act on the system under test/unit]

           // Assert

                [Validate the result]

  2.Add ttsbegin/ttscommit/ttsabort 来进行事务处理,保证数据库不包括不完整的操作结果。

    Ttsbegin-------开始事务处理,
    Ttscommit----提交事务处理,
    Ttsabort-------回滚事务处理

   只有全部语句都成功执行后,事务处理才算成功;
  若其中有一个语句执行失败,则整个处理就算失败,
  并恢复到处理前的状态。

  3.Do ensure a test has at least one assertion or expected exception.

  4.Use data provider if you use existing data in demo data.

  5.在准备数据时,关于插入的数据是自己insert进去的,至于把什么值插入到哪张表里面是根据class中的分支,找到的依据,以及表和表的关系,如果有query,在query中找到的依据,进行总结,总结出共有多少种测试点,尽可能的覆盖所有的分支情况,从而将测试点写成代码UT,从而验证代码的逻辑是否符合功能需求。

                                                              

                                                              博主:海宁

联系:[email protected]

 


时间: 2024-10-12 13:22:09

我的单元测试之总结的相关文章

单元测试之Stub和Mock

单元测试之Stub和Mock FROM:http://www.cnblogs.com/TankXiao/archive/2012/03/06/2366073.html 在做单元测试的时候,我们会发现我们要测试的方法会引用很多外部依赖的对象,比如:(发送邮件,网络通讯,记录Log, 文件系统 之类的). 而我们没法控制这些外部依赖的对象.  为了解决这个问题,我们需要用到Stub和Mock来模拟这些外部依赖的对象,从而控制它们 阅读目录 实例 设计测试用例 什么是外部依赖 Stub和Mock的相同

谈谈单元测试之(四):测试工具 TestNG

前言 上一篇文章<测试工具 JUnit 4>中提到了 JUnit 4,并对 JUnit 4 做了简单的讨论,这篇文章我们将要围绕另一款测试工具讨论 -- TestNG.其实,这篇文章应该写在<测试工具 JUnit 3>之后,和<测试工具 JUnit 4>之前,为什么这么说呢? 那是因为,TestNG 是在 JUnit 3 之后出来了,而 JUnit 4 是在 TestNG 推出之后,综合 JUnit 3 的优点,并且借鉴了 TestNG 的优势,才推出的.但是,考虑到,

谈谈单元测试之(三):测试工具 JUnit 4

前言 上一篇文章<测试工具 JUnit 3>简单的讨论了 JUnit 3 的使用以及内部的方法.这篇文章将会在 JUnit 3 的基础上,讨论一下 JUnit 4 的新特性.同时,与 JUnit 3 做一个简单的对比.那么,废话就不多说了,直接进入正题. 介绍 JUnit 4.x 是利用了 Java 5 的特性(Annotation)的优势,使得测试比起 3.x 版本更加的方便简单,JUnit 4.x 不是旧版本的简单升级,它是一个全新的框架,整个框架的包结构已经彻底改变,但 4.x 版本仍然

单元测试之测试方法

单元测试面临的困难 职责不明确 类或者方法的职责不明确,违反了SRP原则. 类/方法如果处理了本不该它处理的逻辑,会造成单元测试需要关心过多的外部关联类. 静态方法 静态方法使得调用者直接面对实际的服务类,难以通过其它方式替代其实现,也难以扩展. 直接访问对象实例 调用者直接实例化服务对象,从而使用服务对象提供的服务.同静态方法一样,调用者直接面对服务类. 标准库 标准库中有非常多的接口调用使得调用者难以被测试. 准备数据 编写测试用例需要外部准备大量的数据. 可行的解决方案 重构系统 对于职责

单元测试之NSNull 检测

Unit Testing: 单元测试 测试这个词很容易理解,那么什么是单元(Unit)呢?一个单元指的就是应用程序中可以测试的最小单元.一组源代码可以测试,一般要求有明确的输入与输出.因此一般来说源代码中明确的包含输入输出的每一个方法被认为一个测试的单元(一个case).注意,这里的输出并不局限于方法的返回值对输入参数的改变,也包括方法在执行过程中改变的任何数据. 单元测试在程序里面可以理解一个模块一个方法,在每个可能存在的模块都进行测试,确保每个模块都没有问题,从而提高整体程序的质量. 单元测

Visual Studio 单元测试之二---顺序单元测试

原文:Visual Studio 单元测试之二---顺序单元测试 此文是上一篇博文:Visual Studio 单元测试之一---普通单元测试的后续篇章.如果读者对Visual Studio的单元测试不熟悉的话,请先参看上一篇.http://blog.csdn.net/tjvictor/archive/2011/02/09/6175362.aspx 本文会自动略去上篇中提到过的相关概念.方法.本文的例子可以使用下面的链接下载: http://download.csdn.net/source/30

单元测试之Mock

为什么需要Mock. 真实对象具有不确定的行为.所以会产生不可预测的结果. 真实对象很难被创建. 真实对象的某些行为很难被触发(如网络错误). 真实对象令程序的运行速度很慢. 真实对象有(或者是)用户界面. 测试需要询问真实对象它是如何被调用的. 真实对象实际上并不存在.例如其它小组开发的模块. 使用Mock的3个步骤 使用一个接口来描述该对象. 为产品代码实现该接口. 以测试为目的,在Mock对象中实现该接口. Test Double Dummy.被传递但是从不被实际使用的对象.通常用于填充参

玩转单元测试之Testing Spring MVC Controllers

玩转单元测试之 Testing Spring MVC Controllers 转载注明出处:http://www.cnblogs.com/wade-xu/p/4311657.html The Spring MVC Test framework provides first class JUnit support for testing client and server-side Spring MVC code through a fluent API. Typically it loads t

玩转单元测试之WireMock -- Web服务模拟器

玩转单元测试之WireMock -- Web服务模拟器 WireMock 是一个灵活的库用于 Web 服务测试,和其他测试工具不同的是,WireMock 创建一个实际的 HTTP服务器来运行你的 Web 服务以方便测试. 它支持 HTTP 响应存根.请求验证.代理/拦截.记录和回放, 并且可以在单元测试下使用或者部署到测试环境. 它可以用在哪些场景下: 测试移动应用依赖于第三方REST APIs 创建快速原型的APIs 注入否则难于模拟第三方服务中的错误 任何单元测试的代码依赖于web服务的 目