A 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 →

This is a report from a team at a leading financial company:

Continue reading ATDD Lets Team Frequently Release Software →

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 →

It’s helpful to understand the big picture of an application before getting down into the details. The context diagram and the workflow diagram are two ways to show it. This big picture helps in creating acceptance tests for the system that have minimal redundancy and ease of maintenance. In order to demonstrate the two diagrams, I’ll use an example of an on-line ticket ordering system. Continue reading Using Context and Flow Diagrams For a Big Picture →

There is a growing use of services and micro-services to develop applications. I’ve had numerous questions about how to test the services and who should be responsible for what testing. I wrote a book called Interface-Oriented Design which covered many of these issues. Here’s a summary and example adapted from that book. Continue reading Testing Contracts for Services →