BL
Code is always unambiguous - using it to describe a small piece of code behavior (a unit, TDD) is the natural way. However, for "bigger" behaviors, human language can be more beneficial (BDD).
But only for these "bigger" behaviors": Describe every single piece of work necessary to execute in isolation a small functionality is bloated - unit test runners already come with some features for creating some level of abstraction, such as @Before/@After hooks
But only for these "bigger" behaviors": Describe every single piece of work necessary to execute in isolation a small functionality is bloated - unit test runners already come with some features for creating some level of abstraction, such as @Before/@After hooks
Привет
Можете прокомментировать? Пытался объяснить на собеседовании, что-то подобное - что BDD не уходит от предметной области и тестирует действительно сам продукт, а не множество технических ответвлений - не продуктовые тесты в которых может проект повязнуть.
В итоге собеседующие настояли на том, что BDD - это убодный унифицированный framework для общения между всеми: Owner, Dev, QA, Analitics, PM.
Да, про общий язык я согласен, но то что они не поняли сам BDD - это печально... Т.к. сам не использовал BDD, может кто-либо использующий давно прокомментировать своё видение на методологию BDD? И BDD в сравнении с TDD
Можете прокомментировать? Пытался объяснить на собеседовании, что-то подобное - что BDD не уходит от предметной области и тестирует действительно сам продукт, а не множество технических ответвлений - не продуктовые тесты в которых может проект повязнуть.
В итоге собеседующие настояли на том, что BDD - это убодный унифицированный framework для общения между всеми: Owner, Dev, QA, Analitics, PM.
Да, про общий язык я согласен, но то что они не поняли сам BDD - это печально... Т.к. сам не использовал BDD, может кто-либо использующий давно прокомментировать своё видение на методологию BDD? И BDD в сравнении с TDD
