Comments 3
Немного сумбурно всё написано:
0. Given-When-Then они однозначно соответствуют сущностям используемым в большинстве классических определений теста (состояние до — действие — состояние после). Идея в этом, а упомянутое ограничение количества ассёртов это скорее следствие (опциональное и связанное с реализацией).
1. Смесь английского, русского и комбинированного в заголовке как бы намекают что дальше легче не будет, но
2. Хочу предупредить других читателей, что им может таки быть интересно проверить работу с invalid user переданным как validUser именованным параметром.
0. Given-When-Then они однозначно соответствуют сущностям используемым в большинстве классических определений теста (состояние до — действие — состояние после). Идея в этом, а упомянутое ограничение количества ассёртов это скорее следствие (опциональное и связанное с реализацией).
1. Смесь английского, русского и комбинированного в заголовке как бы намекают что дальше легче не будет, но
2. Хочу предупредить других читателей, что им может таки быть интересно проверить работу с invalid user переданным как validUser именованным параметром.
Нас не интересуют вариации validUser'а. Он не нулевой, у него всегда есть id, на то он и valid. Это и есть precondition, т.е. given.
public User enrichUser(User validUser){
user.setDetails(enrichmentService.getUserDetails(validUser.getId()));
return user;
}
0
Насчет английского вы правы, но однозначной русской терминологии кажется нет, т. е. ей никто особо не пользуется.
А насчёт инвалид юзера, если идти в эту сторону, то придётся проверять и что сервис на самом деле делает, и детали его откуда. И в том ли мы приложении и том ли контексте. Т. е. у паранойи предела нет.
0
А насчёт given — так я вообще не про теорию, я про то как пользоваться и зачем.
0
Sign up to leave a comment.
Given, when, ассерты и доверие к имплементации