Spock Extension - 从数据表中提取变量名
Spock Extension - Extracting variable names from Data Tables
为了提取数据 table 值以用于 Spock 的报告扩展,我使用
以下代码:
@Override
public void beforeIteration(IterationInfo iteration) {
Object[] values = iteration.getDataValues();
}
这个returns对我来说是对数据table中对象的引用。但是,我想得到
引用该值的变量的名称。
例如,在下面的测试中:
private static User userAge15 = instantiateUserByAge(15);
private static User userAge18 = instantiateUserByAge(18);
private static User userAge19 = instantiateUserByAge(19);
private static User userAge40 = instantiateUserByAge(40);
def "Should show popup if user is 18 or under"(User user, Boolean shouldShowPopup) {
given: "the user <user>"
when: "the user do whatever"
...something here...
then: "the popup is shown is <showPopup>"
showPopup == shouldShowPopup
where:
user | shouldShowPopup
userAge15 | true
userAge18 | true
userAge19 | false
userAge40 | false
}
有没有办法接收字符串“userAge15”、“userAge18”、“userAge19”、“userAge40”而不是它们的值?
这样做的动机是对象 User 很复杂,包含很多信息,例如名字、姓氏等,它的 toString() 方法会使我生成的报告中的 where 子句不可读。
您可以使用 specificationContext.currentFeature.dataVariables
。它 returns 包含数据变量名称的字符串列表。这应该适用于 Spock 1.3 和 2.0。
编辑:哦抱歉,您不需要数据变量名称 ["a", "b", "expected"]
,而是 ["test1", "test1", "test2"]
。抱歉,我无法为您提供帮助,如果可以的话我也不会,因为那是一种糟糕的 IMO 编程方式。我宁愿确保 toString()
输出以适当的方式缩短或修剪,如有必要,或者(另外或代替)打印 class 名称 and/or 对象 ID。
最后但同样重要的是,编写测试是一种发现应用程序中潜在问题的设计工具。您可能想问自己为什么 toString()
结果不适合在报告中打印并重构这些方法。也许您的 toString()
方法使用换行符,应该简化以打印对象的单行表示。也许您想将多行表示分解为其他方法 and/or 有一组相关方法,如 toString()
、toShortString()
、toLongString()
(之前在 API 中都看到过)或者可能是一些特定的东西,比如 toMultiLineString()
.
OP 显着改变问题后更新:
如果您的扩展程序的用户觉得报告不够清晰,她可以向数据 table 添加一列 userType
,其中包含诸如“15 岁”之类的值。
或者可能更简单,只需添加一个 age
列,其值如 15、18、19、40,并通过 instantiateUserByAge(age)
在 user
列或测试中直接实例化用户given
部分而不是创建大量静态变量。 age
值将由您的分机报告。结合使用 #age
的展开特征方法名称,这应该足够清楚了。
创建用户是否非常昂贵,您必须将它们放入静态变量中?如果不是真的有必要,你要避免静态,因为如果这些对象是 mutable 并且它们的内部状态在一次测试中发生变化,它们往往会对其他测试产生副作用,例如因为有人为了测试setAge(int)
方便地使用了userAge15
。尽量避免通过静态变量进行过早的优化,这通常只会节省微秒。即使您确实决定预先创建一组用户并在所有测试中重新使用它们,您也可以将它们放入以年龄为键的地图中,并从您的特征方法中方便地检索它们,同样只需使用年龄数据 table 作为查询地图的输入值,可以直接查询也可以通过辅助方法查询。
底线:我认为您不必为了迎合编写错误测试的用户而更改您的扩展。这些用户应该学习如何编写更好的测试。作为副作用,报告也将看起来更全面。
为了提取数据 table 值以用于 Spock 的报告扩展,我使用 以下代码:
@Override
public void beforeIteration(IterationInfo iteration) {
Object[] values = iteration.getDataValues();
}
这个returns对我来说是对数据table中对象的引用。但是,我想得到 引用该值的变量的名称。
例如,在下面的测试中:
private static User userAge15 = instantiateUserByAge(15);
private static User userAge18 = instantiateUserByAge(18);
private static User userAge19 = instantiateUserByAge(19);
private static User userAge40 = instantiateUserByAge(40);
def "Should show popup if user is 18 or under"(User user, Boolean shouldShowPopup) {
given: "the user <user>"
when: "the user do whatever"
...something here...
then: "the popup is shown is <showPopup>"
showPopup == shouldShowPopup
where:
user | shouldShowPopup
userAge15 | true
userAge18 | true
userAge19 | false
userAge40 | false
}
有没有办法接收字符串“userAge15”、“userAge18”、“userAge19”、“userAge40”而不是它们的值?
这样做的动机是对象 User 很复杂,包含很多信息,例如名字、姓氏等,它的 toString() 方法会使我生成的报告中的 where 子句不可读。
您可以使用 specificationContext.currentFeature.dataVariables
。它 returns 包含数据变量名称的字符串列表。这应该适用于 Spock 1.3 和 2.0。
编辑:哦抱歉,您不需要数据变量名称 ["a", "b", "expected"]
,而是 ["test1", "test1", "test2"]
。抱歉,我无法为您提供帮助,如果可以的话我也不会,因为那是一种糟糕的 IMO 编程方式。我宁愿确保 toString()
输出以适当的方式缩短或修剪,如有必要,或者(另外或代替)打印 class 名称 and/or 对象 ID。
最后但同样重要的是,编写测试是一种发现应用程序中潜在问题的设计工具。您可能想问自己为什么 toString()
结果不适合在报告中打印并重构这些方法。也许您的 toString()
方法使用换行符,应该简化以打印对象的单行表示。也许您想将多行表示分解为其他方法 and/or 有一组相关方法,如 toString()
、toShortString()
、toLongString()
(之前在 API 中都看到过)或者可能是一些特定的东西,比如 toMultiLineString()
.
OP 显着改变问题后更新:
如果您的扩展程序的用户觉得报告不够清晰,她可以向数据 table 添加一列 userType
,其中包含诸如“15 岁”之类的值。
或者可能更简单,只需添加一个 age
列,其值如 15、18、19、40,并通过 instantiateUserByAge(age)
在 user
列或测试中直接实例化用户given
部分而不是创建大量静态变量。 age
值将由您的分机报告。结合使用 #age
的展开特征方法名称,这应该足够清楚了。
创建用户是否非常昂贵,您必须将它们放入静态变量中?如果不是真的有必要,你要避免静态,因为如果这些对象是 mutable 并且它们的内部状态在一次测试中发生变化,它们往往会对其他测试产生副作用,例如因为有人为了测试setAge(int)
方便地使用了userAge15
。尽量避免通过静态变量进行过早的优化,这通常只会节省微秒。即使您确实决定预先创建一组用户并在所有测试中重新使用它们,您也可以将它们放入以年龄为键的地图中,并从您的特征方法中方便地检索它们,同样只需使用年龄数据 table 作为查询地图的输入值,可以直接查询也可以通过辅助方法查询。
底线:我认为您不必为了迎合编写错误测试的用户而更改您的扩展。这些用户应该学习如何编写更好的测试。作为副作用,报告也将看起来更全面。