Size: a a a

Heisenbug, конференция по тестированию

2019 January 31

AV

Alexei Vinogradov in Heisenbug, конференция по тестированию
Надо ж понять сперва, что мы теряем:-)
источник

VL

V L in Heisenbug, конференция по тестированию
Поправлюсь. Использование геркин способствует степам.
Использование геркин =/= БДД
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
Потому что задача не в этом. Не в том чтобы юнит-тесты запускать через кукумбер :)
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
Смысл бдд вкратце в том, чтоб сразу понимать definition of done, до того как код писать.

А смысл юнит-тестов и пирамиды в другом. Поэтому делать одно через другое - немного не то, что хотелось бы :)
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
V L
Поправлюсь. Использование геркин способствует степам.
Использование геркин =/= БДД
Для степов есть и поудобнее инструменты чем геркин. Тот же аллюр
источник

VL

V L in Heisenbug, конференция по тестированию
Алюр тебя дает повесить анотацию куда угодно на любую функцию не принуждая иметь уровень тест степов Ты уже должен писать в хорошем стиле.
У кукумбера уровень степов част архитектуры
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
У кукумбера и свои ограничения есть при этом, ненужные, типа шаред контекст для передачи состояния между степами. В нормальном фреймворке обычно без этого обходится. Но это не суть, можно и с геркином жить, если он устраивает, дело привычки
источник

S

SaneQ in Heisenbug, конференция по тестированию
V L
Алюр тебя дает повесить анотацию куда угодно на любую функцию не принуждая иметь уровень тест степов Ты уже должен писать в хорошем стиле.
У кукумбера уровень степов част архитектуры
как повесить аннотацию на ассерт в тесте?
источник

VL

V L in Heisenbug, конференция по тестированию
Можно через аспекты если в java
источник

VL

V L in Heisenbug, конференция по тестированию
Если надо на стандартный ассерт повесить
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
Если действительно захотеть, можно на что угодно аннотацию навесить, только надо помнить о цели и понимать зачем это делать
источник

AV

Alexei Vinogradov in Heisenbug, конференция по тестированию
Ой тут намешали коней с людьми...
источник

VL

V L in Heisenbug, конференция по тестированию
Alexander Tarankov
У кукумбера и свои ограничения есть при этом, ненужные, типа шаред контекст для передачи состояния между степами. В нормальном фреймворке обычно без этого обходится. Но это не суть, можно и с геркином жить, если он устраивает, дело привычки
+
источник

AV

Alexei Vinogradov in Heisenbug, конференция по тестированию
Alexander Tarankov
Смысл бдд вкратце в том, чтоб сразу понимать definition of done, до того как код писать.

А смысл юнит-тестов и пирамиды в другом. Поэтому делать одно через другое - немного не то, что хотелось бы :)
Ну допустим, да, чтобы разные роли одинаково понимали требования и могли автоматизированно проверить, удовлетворяет софт им или нет.

Но при чём тут пирамида или юнит-тесты?
источник

AV

Alexei Vinogradov in Heisenbug, конференция по тестированию
БДД ничего про пирамиду не говорит
источник

VL

V L in Heisenbug, конференция по тестированию
Alexei Vinogradov
БДД ничего про пирамиду не говорит
+
Бдд говорит что на входе есть спецификация в виде сценария поведения
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
Там чуть выше началось с того, что я поспрашивал не смешивал ли кто БДД и пирамиду. Но не так чтоб по жёсткому из степов юнит-тесты звать, а чтоб для е2е использовать БДД и при этом сохранить принцип минимума е2е тестов, а побольше проверять на нижних уровнях, когда это осмысленно.

То есть, есть некое противоречие БДД и пирамиды в части упора на е2е. Как их разумно сочетать? Кто что думает?
источник

VL

V L in Heisenbug, конференция по тестированию
Бдд не говорит о том чтобы писать много e2e тестов. Это уже разработчики решают. Трансляция такой  bdd спеки в executable scenario имхо не обязательно.
Если же хочется чтобы на каждую был executable scenario ,  покрыть вариативность можно лучше на уровнях нижн и не тянуть в e2e
источник

AT

Alexander Tarankov in Heisenbug, конференция по тестированию
БДД тесты будет ПМ писать иначе нет смысла в БДД. Вот он и нафигачит своих е2е проверок.

Ок, видимо решение здесь такое, чтоб разъяснить ПМ-у сколько тестов достаточно
источник

AV

Alexei Vinogradov in Heisenbug, конференция по тестированию
Alexander Tarankov
Там чуть выше началось с того, что я поспрашивал не смешивал ли кто БДД и пирамиду. Но не так чтоб по жёсткому из степов юнит-тесты звать, а чтоб для е2е использовать БДД и при этом сохранить принцип минимума е2е тестов, а побольше проверять на нижних уровнях, когда это осмысленно.

То есть, есть некое противоречие БДД и пирамиды в части упора на е2е. Как их разумно сочетать? Кто что думает?
Нет никакого противоречия, БДД нигде не упоминает e2e, я тоже с этого начал.
источник