Как добавить модульный тест для enum в spock?
У меня ниже класс enum
public enum EmployeeType {
PERMANENT("10"),
TEMPORARY("20"),
PART_TIME("30");
private final String employeeTypeId;
EmployeeType(final String employeeTypeId) {
this.employeeTypeId = employeeTypeId;
}
public String getEmployeeTypeId() {
return employeeTypeId;
}
}
Попытка с приведенной ниже спецификацией
class EmployeeTypeSpec extends Specification {
@Unroll
def "validate emp type"(EmployeeType employeeType) {
expect:
// want to assert each employeeType name() and employeeTypeId here
employeeType.name()
employeeType.employeeTypeId
where:
employeeType << EmployeeType.values()
}
}
Здесь я передаю каждое значение перечисления, используя метод values(). но не знаете, как утвердить имя и employeeTypeId для каждого перечисления?
EmployeeType.name() == 'PERMANENT' employeeType.employeeTypeId == '10', вот так я хочу утверждать каждый служащий
Почему вы хотите протестировать name()?
Не конкретно имя (). хотите подтвердить каждое свойство каждого перечисления
Я бы не стал использовать .value() в блоке where для тестирования того, о чем вы говорите. Я бы, наверное, написал тест как EmployeeType.PERMANENT. employeeTypeId == '10' и т. д.
Получил вашу точку зрения. вместо этого EmployeeType.PERMANENT. employeeTypeId == '10', я пытаюсь найти решение с блоком where для проверки каждого значения перечисления
«Я пытаюсь найти решение с блоком where для проверки каждого значения перечисления» - я понимаю. Причина, по которой я не опубликовал свой комментарий в качестве ответа, заключается в том, что он не говорит вам, как это сделать. Я говорю, что делать это, вероятно, не очень хорошая идея.
Ответы 1
Что-то вроде этого, вероятно, будет иметь больше смысла, чем employeeType << EmployeeType.values():
def "Test enum values"() {
expect:
value.employeeTypeId == typeId
where:
// could have more columns here if the enum
// had more properties...
value | typeId
EmployeeType.PERMANENT | '10'
EmployeeType.TEMPORARY | '20'
EmployeeType.PART_TIME | '30'
}
На самом деле это не относится к будущим модификациям, т. е. не гарантирует охват новых случаев.
"это не гарантирует охват новых случаев" - Вы правы. Это гарантирует, что typeId имеет ожидаемое значение. Если бы перечисление имело другие свойства, их можно было бы опросить.
Просто хотел отметить, что тест OPs также обнаружит новые значения перечисления, поскольку он использует EmployeeType.values(). Таким образом, вы можете либо сделать канареечный тест, который просто проверяет, что размер перечисления все еще является ожидаемым 3. В качестве альтернативы вы можете использовать [value, typeId] << [EmployeeType.values(), ['10', '20', '30']].transpose(), при условии, что таблица данных читается лучше, но это начнет давать сбой, если новое значение перечисления было добавлено без обновления теста.
«Хотел отметить, что тест OP также обнаружит новые значения перечисления, поскольку он использует EmployeeType.values ()» — верно, но нет полезных общих утверждений, которые можно сделать о новых значениях перечисления без повторного посещения теста. . Если вы предпочитаете использовать подход .values() и он более прост для вас, сделайте это. Я бы не стал.
Я пытаюсь сказать, что по крайней мере один тест должен начать давать сбой, если новое значение перечисления будет добавлено без повторного посещения и обновления этого теста.
«Хотите утвердить каждое имя employeeType () и employeeTypeId здесь» — какое утверждение вы хотели бы сделать о каждом из них?