在代码签入之前运行测试

很久没有写文章,看着每天仅有的可怜的访问量,实在觉得对不起读者,决定再写点什么吧。

测试工程师应该做什么?如何体现测试工程师的价值?类似的问题如果放到一些测试会议或者沙龙上讨论,估计一定很热闹。每个人心中都有自己的认识和答案。我个人理解的较为简单,假如整个团队没有测试,会达得到什么样的一种成就?那假如把测试加进去这个团队,能否帮助大伙提高成就?如果测试是在做正功,那么就是有价值,至于价值多少不容易衡量,如果测试在做负功,那还是自求多福吧。

软件天生就有缺陷(Defect, Bug),缺陷从哪来?缺陷从不平白无故地出现,它总是伴随着功能(Feature)而来,谁创造了功能?随便啦,但是最后通常来是开发工程师动手的,所以大部分时间开发都会负责修bug。一般的流程都是:1. 写了一些功能; 2. 测试;3. 发现一些bug;4. 修bug。如果我们可以加速这个反馈的时间,那么也算是做了正功了。

在网上找到一张很好的图: http://www.jetbrains.com/teamcity/features/delayed_commit.html 很好的解释了怎么样在真正提交代码之前运行测试。至于如何做,基本上每个代码管理工具都有类似的支持,例如Git的Hook: http://git-scm.com/book/en/Customizing-Git-Git-Hooks, 又例如一个号称更加好的Hook:https://github.com/jish/pre-commit,SVN也行:http://svnbook.red-bean.com/en/1.7/svn.ref.reposhooks.pre-commit.html

我只分享一下我自己在使用上的一些经验:

  • 如果你的测试是Flaky的,不要放在pre-commit里面去。一切看起来很没好,但是如果当开发经常在写完一段代码正准备提交的时候,被一个fail的测试挡住了,然后花了半天时间发现不是他的代码有问题而是测试有问题,结果谁都不太爽
  • 不要把大量的end to end测试放在pre-commit里面跑,想一下让你跑10分钟测试才能提交代码,你能不抓狂吗?
  • 要让开发写测试,而不是测试工程师写测试。这样做的好处是开发自己了解测试代码,可以自己修改测试,更新测试,而不需要等测试来做修复。另一方面,产品质量真的不是测试工程师能保证的,大家测才是真的测
  • 不要在刚开始的时候就添加过多的测试,少量的测试总是比较容易跑过并且让大家接受
  • pre-commit测试不是万能,千万不要生搬硬套

单元测试中的异常处理

最近项目不是十分多,所以大部分的学习来自于书本还有同行的博客,淘宝的QA Team博客就是一个很好博客,里面N多淘宝的工程师写,而且更新的非常频繁,质量也很好。翠翠同学以后就要加入淘宝了,以后就能看到他写的博客了。

早上来看到一篇文章,大概讲的是在单元测试中容易用到了Try…Catch语句而容易出现的一个错误,这里想说一下我对单元测试中异常处理的。记得一个牛人曾经说过(实在想不起来谁也搜不到),大概的意思就是“处理一个问题的最好的办法就是不去处理它”。我不知道当时他讲这句话的具体场景是什么,不过我觉得这句话用在单元测试的异常处理中还是比较合适的。

首先来看看两条关于异常处理的原则

  • 如果无法处理某个异常,那么就不要捕获它
  • 如果捕获到一个异常,那么不要胡乱处理它

单元测试的代码和开发的生产代码,虽然同是程序代码,但是他们存在的意义是不一样的。前者是验证程序的正确性,属于为程序服务的;后者是实现某种功能,属于为客户服务的。然后在看上面的两条异常处理的原则。
Continue reading “单元测试中的异常处理”

测试代码重构实例

Martin Fowler的《重构》这本书基本上每个程序员都会看,对于做单元测试的测试工程师来说,测试的代码本身也是程序,也需要重构。最近在看《XUnit Test Patterns》,把以前的做的东西重新梳理了一下,并且落实到新的项目中。

首先来看看一个最原始的单元测试代码:

[TestMethod]
public void GetPaymentAccountByOwnerID()
{
	int ownerId = 1300100000;
	//Delete the account
	TestHelper.DeletePaymentAccountByOwnerId(ownerId);

	//Here should be create an account
	PaymentAccount paymentAccount = PaymentGateway.PaymentProvider.GetPaymentAccountByOwnerID(ownerId, AccountOwnerType.NormalUser);

	//Verify the payment account instance
	Assert.IsTrue(paymentAccount.AccountID > 0);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.CreateTime.DayOfYear);
	Assert.AreEqual(DateTime.Now.DayOfYear, paymentAccount.UpdateTime.DayOfYear);
	Assert.AreEqual(0, paymentAccount.Balance, 0.0001);
	Assert.AreEqual(0, paymentAccount.AvailableBalance, 0.0001);
	Assert.AreEqual(0, paymentAccount.FreezeAccount, 0.0001);
}

以上是个很简单的单元测试代码,应用了AAA原则,首先做好准备(删掉原有的数据),然后执行测试,最后再验证返回结果。看起来很好也很清晰。首先发现一个问题,就是那一堆Assert让人觉得迷惑,究竟想干啥?其实那6句Assert都是验证程序返回的PaymentAccount对象是是否符合设计。我把这些Assert语句提取出来,作为一个方法,让测试代码更加容易让人明白。也就有了版本2。
Continue reading “测试代码重构实例”

单元测试中三种准备Test Fixture的方法比较

首先说一下Test Fixture,我不知道怎么样翻译这个Test Fixture,没能搜到一个翻译的比较合适的。最让我气愤的是某人翻译的一本书中,直接把Test Fixture翻译成为测试夹具,这明显就是什么词霸词典硬翻译出来的,我强烈鄙视这样不负责任的翻译行为。

The test fixture is everything we need to have in place to exercise the SUT

我觉得这是一个对Test Fixture的一个很清晰明了的定义,就是运行被测软件所需要的一切东西,这个“东西”不单只是数据,同时还包括对被测软件的准备,例如实例化某个被测方法所在的类,准备数据库的ConnectionString等。通常来说,有三种方法来准备Test Fixture。

1. 内联方式:这种方式就是直接在测试方法中编写准备Test Fixture的代码。用这种方法的缺点是很容易造成代码的重复,出现很多复制粘贴的代码。同时,如果这个SETUP的过程比较复杂,也会降低测试代码的可读性,可维护性。另外的一个问题就是,这种方法很容易会带来测试数据Hard code的隐患。既然有那么多缺点,这种方法还有什么生命力呢?首先,可能对于初学者来说,这种方法是最简单的;其次,在一些只需要准备简单的Test Fixture的场合中,这种方法还是给编写测试的人提供了便利。
Continue reading “单元测试中三种准备Test Fixture的方法比较”

控制反转有助于提高程序的可测试性

控制反转,英文是Inversion of Control,简称IoC。这个概念在JAVA的Spring框架中比较常见,在.NET的开发中,Ioc或者其的变种依赖注入DI(Dependency Injection)是不太常见的。一般来说,类A要使用类B,类A会在其内部对类B进行控制,比较典型的做法就是在类A中创建一个类B的实例;而控制反转,就是把一个已经创建好的类B实例交给类A去控制。
例子:
Continue reading “控制反转有助于提高程序的可测试性”

自动化单元测试要点

用单元测试的框架MSTEST,做单元测试,集成测试快1年了,总结一下工作中学到都东西。

单元测试,集成测试有什么用?

1. 改进产品质量

软件测试,很多时候围绕着两个问题:

Verification和Validation,常说的双V。前面的Verification就是Is the software built correctly?。后面的Validation就是Have we built the right software?

单元测试,更多的是Verification。所以有时候经过我单元测试和集成测试以后的功能模块,在交给其他同事做功能测试的时候,依然会有一些BUG,这时候开发可能会埋怨我测试得不够完全,诸如此类。但是其实很多时候,我的关注点是单个方法的功能、行为,没有站到更高的位置来测试这个模块。对于这样的问题,开发和测试应该互相体谅,我本人也会提高自身的水平。希望在单元测试和集成测试中也加入更多关于Validation的思考。
Continue reading “自动化单元测试要点”

自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG

在12月的时候,我在博客里面介绍了一个自动化单元测试工具–PEX。在上一篇博客中,又讲述了微软ZUNE在闰年最后一天死机的原因。现在把这两篇文章串起来,跟大家分享一下如何用PEX帮助改善代码的质量。

首先来看一下用PEX测试ZUNE处理日期的方法的结果,如图:


Continue reading “自动化白盒测试工具PEX应用实例 – 发现ZUNE死机的BUG”

微软ZUNE死机原因–单元测试百分百语句覆盖率是不够的

微软的30GB版本Zune在08年的最后一天出现了大规模死机的现象,原因其实就是一行代码原本应该写为大于等于,但是实际上写成了大于。下面来看看具体的代码,第5行就是导致死机的代码。

while (days > 365)
{
	if (DateTime.IsLeapYear(year))
	{
		if (days > 366)
		{
			days -= 366;
			year += 1;
		}
	}
	else
	{
		days -= 365;
		year += 1;
	}
}

Continue reading “微软ZUNE死机原因–单元测试百分百语句覆盖率是不够的”

在ASP.NET单元测试中进行调试

在前一篇关于在单元测试中使用HttpContext的文章中,本人提到了用ASP.NET单元测试的一个缺点是不能调试,今天我推翻我自己错误的论调,其实在ASP.NET单元测试中也是能调试的。

以前我以为ASP.NET单元测试就运行于WEB服务器上,所以我用Debug来运行,那么ASP.NET单元测试就自动Attach到Web服务器,就能调试了。但是实际上要让ASP.NET单元测试可以调试的话,正确的做法应该是:

  1. 在Web.config中,找到<compilation debug=”false”/>这个节点,然后把debug属性改为true
  2. 在ASP.NET单元测试代码的最开始处添加这样一句话“System.Diagnostics.Debugger.Break()”
  3. 运行该ASP.NET单元测试

在运行单元测试的时候,会有一个提示框出来,说程序遇到一个断点,是否进入调试,当然是选择调试啦。如图:
Continue reading “在ASP.NET单元测试中进行调试”

在C#单元测试中使用HttpContext的简单解决办法

场景:最近在测试一个.NET的Http Module,这个Module是用来做URL重写的。刚开始进展的比较顺利,因为该Module里面的方法参数基本上都是String,后来这个Module进行了一下重构,所有参数都变成了HttpContext了,这就直接导致原来的单元测试都跑不起来了,接着就开始了弄HttpContext了。

1. 采用Visual Studio自带的ASP.NET单元测试

刚开始我看了一下被测试的代码,虽然说用到了HttpContext,但是有很多地方我都可以绕过去的,意思就是这个HttpContext只是名以上需要的一个参数,只要它不是NULL就可以了,并不影响我的测试,所以我采用了ASP.NET Unit Test的办法来获取一个HttpContext,这个方法实现起来是最简单的,但是会有一些问题,后面会提及到。
Continue reading “在C#单元测试中使用HttpContext的简单解决办法”