Gojko Adzic asked for opinions in his blog “How to Specify Something Should Be Random. He presented alternative scenarios and asked for your choice.
The situation he described is having a robot’s chat response appear like it comes from a human being. There could be multiple levels of tests associated with this requirement. Let’s take a look at these levels and along the way give my choice(s) for an answer. Continue reading Layers of Scenarios and a Reply on Randomness
“How to organize feature files?” was a question asked by Gojko Adzic in a recent blog. He presented several options and then asked for responses. The options included grouping them by user story, by capability and level of detail. This question has often come up over the past years in the workshops that I teach.
Continue reading Organizing Your Feature FilesA blog question on relative dates by Gojko Adzic triggered a blog post by Seb Rose. The two blog posts showed there are many shades of gherkin. I’d like to use the example in those two posts to demonstrate a couple of facets of scenario decomposition. This uses a slightly different shade than Seb’s.
Continue reading Decompose Scenarios for Simpler ScenariosA blog on specflow.org talked about ways to document scenarios for a business rule. It reminded me about some aspects of blog wrote a few years ago called Six Shades of Gherkin. Here’s the business rule that was used as the example in specflow.org blog:
A volume discount rule provides 10% off for purchases between 5 and 10 items, 15% for purchases between 10 and 20; and 20% above that.
One of the issues with business rules is making sure they are understood by the entire triad (customer, developer, tester). In this example, what is the discount for 10 items? One way to document is to use a scenario outline that gives the results for each side of each breakpoint. Another important value is documenting the results at the limits and beyond. Continue reading A Few Shades of Gherkin For Business Rules
A common format for scenarios is Given/When/Then. The Gherkin language revolves around the Given/When/Then organization. Scenarios can be written in Gherkin in many variations, each of which has a different shade of meaning. These shades I’ve denoted as outline, values, domain terms, table values, calculation, and chatty.
This is a report from a team at a leading financial company:
Cucumber is usually considered a customer acceptance test automation tool. However, it can also be used as more of a unit testing tool in place of JUnit or other language-based tools. This can make those tests better and more understandable, with the probably of better maintainable code underneath. Continue reading Using Cucumber for Unit Tests
There is often a question as to whether a test such as a business rule should be made more generic. In this article, we’ll examine ways of making tests more generic.
Continue reading Generifying Acceptance Tests
You can write test double for all the external entities of an application, such as an email server, a credit card processor, or an enterprise database. But you still have to check that you’ve made the right connection to all of these. How do you do that? Continue reading So Much for Test Doubles, What About Testing the Real Thing?
There is a common testing pyramid that many organizations use regarding end-to-end, integration, and unit tests. Analogous to this pyramid, acceptance tests that are developed by the triad (customer unit, developer unit, and tester unit) can be applied at various levels. This blog entry relooks at the context diagram shown in this article, but from the standpoint of testing. Continue reading Acceptance Tests and the Testing Pyramid