在单元/功能测试中,应该测试多少GORM功能是否存在“最佳实践”或事实标准?要测试多少Grails GORM?
我认为应该做大部分域测试作为功能测试,以便获得完整的grails环境。但是你测试了什么?插入,更新,删除?您是否测试了约束,即使它们可能通过grails发布进行了更彻底的测试?
或者你是否假设GORM做了它应该做的事情并转移到应用程序的其他部分?
在单元/功能测试中,应该测试多少GORM功能是否存在“最佳实践”或事实标准?要测试多少Grails GORM?
我认为应该做大部分域测试作为功能测试,以便获得完整的grails环境。但是你测试了什么?插入,更新,删除?您是否测试了约束,即使它们可能通过grails发布进行了更彻底的测试?
或者你是否假设GORM做了它应该做的事情并转移到应用程序的其他部分?
我的一般规则是测试我写的东西。因此,如果我编写自定义方法(或闭包),那么我将单元测试这些方法。这个规则也意味着我会测试约束,因为我已经写了约束。为此,我在GrailsUnitTestCase中使用mockForConstraintsTests()方法。
一个例子constraints块:
static constraints = {
location(blank:true, nullable:true)
make(blank:false, nullable:false)
name(blank:false, nullable:false)
serviceTag(nullable:true)
purchaseDate(blank:false, nullable:false)
checkedDate(blank:false, nullable:false)
warrantyExpirationDate(nullable:true)
notes(blank:true, nullable:true)
}
我将有以下限制单元测试:
void test_null_constraints_are_checked() {
mockForConstraintsTests(Hardware)
def hardware = new Hardware()
assertFalse hardware.validate()
assertEquals 4, hardware.errors.getFieldErrorCount()
assertEquals "nullable", hardware.errors["name"]
assertEquals "nullable", hardware.errors["checkedDate"]
assertEquals "nullable", hardware.errors["purchaseDate"]
assertEquals "nullable", hardware.errors["make"]
}
这将捉对我的约束拼写错误的时候了。
我不测试保存,创建,更新,删除在域;如果这些失败了,那我就有更大的问题!
就我个人而言,我会测试任何复杂的关系,我并不是100%适合设置,并且任何访问器的默认实现被覆盖。
这听起来很合理,我只是担心我正在测试GORM本身而不是我的代码。从某种角度来看,我的映射是我的代码的一部分,我正在测试它。 – 2010-05-05 20:26:06
你会不会测试关系1-M等? – 2010-05-06 00:38:00
我不能说我已经在单元上直接测试过它们。我通常在集成层面上选择它们。 – zentuit 2010-05-06 02:29:35