3 ms·
That's what's predicated by "Specification By Example" [1] practices. Gojko elaborates into the tooling and requirements preservation aspects in "Are tools nec
by vladsanchez 5y ago
That's what's predicated by "Specification By Example" [1] practices.
Gojko elaborates into the tooling and requirements preservation aspects in "Are tools necessary for acceptance testing, or are they just evil?"[2]
[1] https://gojko.net/books/specification-by-example/ https://gojko.net/books/specification-by-example/
[2] https://gojko.net/2010/03/01/are-tools-necessary-for-acceptance-testing-or-are-they-just-evil/ https://gojko.net/2010/03/01/are-tools-necessary-for-accepta...
- mch82 5y agoThank you, I’ll give that book a look. I read the article. After a good amount of time trying Cucumber, I tend to agree with James Shore that specialized acceptance testing tools don’t add enough value to offset the added complexity. I’ve found it more efficient to simply add logging markup to the unit & integration test framework that goes with the language used to implement the app. The most tester-friendly approach I’ve found is to use Storybook for GUI acceptance and Postman for API acceptance. Those tools keep the tests close to the code, organize scenarios well, and are usable by true non-developers. Plus, test collections in Storybook/Postman double as valuable documentation. I hope Storybook stays focused on real, run-time web components and doesn’t get caught up in too much test-only code.