单元测试正是敏捷方法的核心所在。
1.测试是可执行的代码范例,即使文档有过期的风险,测试则会紧跟代码,因为这是编译器强制保证的
2.此外,有了单元测试,就意味着开发者能够持续的对代码进行大胆的重构而无需付出太大的测试成本和风险,进而提高代码的健壮性和系统质量,达到程序员最终的解放。
在Java的世界里,JUnit则是引领这个潮流的弄潮儿,是Java程序员开发工具箱里的必备物资,而对于Groovy而言,测试同样重要,鉴于和Java同根同源的现状,Groovy采用了拿来主义的思想,其测试的第一步就是继承JUnit的父类,完成一系列的增强,让其更加好用(事实上,这句话几乎就是Groovy对待Java的“遗产”上的一贯处理方式),下面我们来做具体了解:
1.Groovy可以和JUnit3一样,继承junit.framework.TestCase抽象类来构造测试。除了一些语法糖,基本用法和Java一样。
2.Groovy可以和JUnit4一样,使用annotation来标记测试方法,@Test,因为JUnit4不要求用户继承固定的父类,所以一般的处理方式是通过静态引入加入Assert这个类,调用其静态的断言方法来实现单元测试的需要。
3.可以继承Groovy自己实现的测试父类groovy.util.GroovyTestCase来实现单元测试,在这个父类里,包含了众多方便的断言方法。比如assertLength和shouldFail等。当然,这种靠继承的方式来实现的测试方法被识别出来的规则和JUnit3一样:方法需要是public,无返回值的,且名字必须以test开头才行。
class LabTest extends GroovyTestCase{
public void testArrayEquals() {
def mm =["a", "b"] as String[]
assertArrayEquals(mm, ["a", "b"] as String[])
}
public void testLength(){
assertLength(3, ["c", "b"] as String[])
}
}
结果为:
junit.framework.AssertionFailedError: expected:<3> but was:<2> *
4.脚本测试,Groovy作为一种便于脚本的语言,脚本测试的便利性也很重要。执行脚本测试,可以使用GroovyShell类来编程式的调用脚本来执行。具体如下面的例子:
import groovy.json.JsonSlurper
def jsonResult = "http://m.weather.com.cn/data/101290401.html".toURL().getText()
def jsonParser = new JsonSlurper().parseText(jsonResult)
jsonParser?.weatherinfo?.with {
println "temp: $temp1 @ city: $city"
}
这个例子打印某个城市的天气,可以获得一个Json的返回值,大致如下:
{
"weatherinfo": {
"city": "哈尔滨",
"temp1": "-5℃~-17℃"
}
}
篇幅所限,这里精简了大部分的结果,只保留了我们脚本需要输出的部分,对于这个脚本,我们需要在使用它之前对它进行合理的测试,我们试试刚说到的GroovyShell类
import static org.junit.Assert.*;
import org.junit.Test;
class GetWeather