使用Groovy语言替代JUnit为Java程序编写单元测试

(本文改编自 @申导 翻译的《有效的单元测试》,如果对本文感兴趣,请支持正版书籍。)

编程是用计算机可理解的语言来表达你的想法和意图。对于Java程序员来说就是编写一种可以由Java编译器编译为可以运行在JVM上的字节码的代码。不止一种编程语言可以编写能运行在JVM上的代码,不过每种JVM语言都具有其独特的语法和感觉,但有一点是相同的:关于在JVM创建应用程序这件事上,她们都号称比Java更加简洁和更具表达力。

另类JVM语言

另类JVM语言的历史可追溯到15年前,那时Jim Hugunin在编写Jython,即一种JVM上的Python语言实现。尽管Jython难以获得发展的动力,但它启发了后来许多JVM语言的出现。

受到Jython的启发,2003年Groovy语言开始在JVM上登场,有着精简语法的Groovy承诺与Java代码之间流畅的互操作性和极高简洁性,使之成为JVM上编写脚本的重要选择。其他运行在JVM平台上的语言还包括Scala, JRuby, Clojure等,以及Java本身。

概括来说,各种另类JVM语言的一些潜在优势在于:

  • 更少的样板代码语法可以去芜存菁
  • 更多的文本(literal)数据结构
  • 针对标准类型的额外方法
  • 更多强大的语法结构

继续阅读 More

单元测试JUnit入门

(下文摘自 申健/ @申导 翻译的《有效的单元测试》附录A)


在Java生态系统中,现如今事实上的单元测试框架是JUnit。年复一年,越来越少的Java程序员没有见过JUnit测试代码了。不过,每个人总有第一次,某些人也可能使用着其他的测试框架,那么我们编写了这个简短的附录,快速地开始用JUnit来编写测试。

理解JUnit有两个基本元素。首先,你必须了解JUnit测试代码的结构和生命周期。我们从这里开始。我们将看一看如何在测试类(test classes)中定义测试方法(test methods),然后熟悉测试的生命周期——JUnit如何以及何时实例化和调用你的测试类及其方法。

其次,就是JUnit的断言(Assertion) API。基本的和常用的断言方法很简单,你看到它们的方法签名就知道如何使用了。因此,我们只会通过名字来调用这些方法,而聚焦于那些缺乏自我解释的更加“不透明”的断言。

总的来说,JUnit是一个小而简单的框架,我毫不怀疑你会快速地学会运行它。最终你会在某些地方卡住,可以求助于专门的JUnit书籍,比如Manning Publication出版的优秀书籍《JUnit in Action (2nd edition)》就会派上用场。在那之前,我希望本附录包含入门需要的全部内容,帮助你跟上本书的其他内容。

继续阅读 More

XCode6 中XCTest支持异步的单元测试

过去因为每个测试是相互独立、顺序执行的,因此单元测试都是同步执行的。为了支持各种异步调用,XCode可以用来新的API和 XCTestExpectation 对象支持block,现在测试方法会等待调用完成或者超时。
一般的过程是,测试用例进行异步操作,并注册回调,然后等待expectation被满足。当异步操作结束时,通常会进入回调函数或者Block,测试案例在这里需要主动告知expectation已经被满足,从而结束run loop的等待,然后可以进行后续断言或操作。

继续阅读 More

所有代码都需要单元测试覆盖吗?

test-coverage

单元测试(unit testing)已经越来越得到广大开发者的认可。作为低成本、速度快、稳定度高的自动化测试手段,单元测试可以在类和函数级别对代码进行质量守护,有助于避免尴尬、耗时的错误。当然,相比功能测试(Functional testing)和端到端测试(end-to-end testing),单元测试能够寄予的产品级别的信心要略低一些,因而各个粒度的测试应该是相辅相成的,互为补充。

常常听到一些组织要求开发团队提高单元测试覆盖率,换来的却是怨声载道,或者是一堆应付差事的垃圾测试(没有断言的测试,都见过吧)。尽管,低测试覆盖率意味着对质量的信心不足,但是,单元测试覆盖率真的要达到100%才好吗?

继续阅读 More