[This article was first published on jakub::sobolewski, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.When developing software, a disconnect between what users want and what the software does can occur. We might’ve delivered working, tested code, but does it solve the user’s problem?Behavior-driven development aims to mitigate that risk, by capturing and testing requirements from the perspective of the external user of the system.How BDD worksWhether we’re working with a Product Owner, with users, or by ourselves, BDD can help us explore and define the problem in a structured way.The process is as follows:We capture a vague wish with a User Story.We refine the User Story into examples. Those examples describe how we can tell if the wish has been fulfilled. Focus on what you want to achieve, not how to achieve it.We create specifications. They are direct translations of examples into code.This helps us move from a vague description to a very precise, testable specification.Capturing a wish with a User StoryLet’s imagine we want to implement a bookstore. The first User Story could be:As a customer, I want to select a book and add it to cart so that I can buy it.Refining the User Story into examplesBehavior-Driven Development helps us focus on behavior, by using a language that expresses behavior:Given some context,When an event occurs,Then an outcome should be observed.In this example, we could write:Given I am in the bookstoreWhen I select “The Hobbit, J.R.R. Tolkien”When I add selected book to the cartThen I should see “The Hobbit, J.R.R. Tolkien” in the cartThis description is more precise than the User Story. It describes what needs to happen, what the user needs to do, and what result the user should see.At this level, we don’t know anything about the implementation of the bookstore. This description fits any implementation of the bookstore:it could be a web application,it could be a CLI application,or it could be a physical store with a robot assistant.The implementation can be changed at any moment, and executing the specification should tell us if the system allows the user to achieve their goal.Implementing executable specificationsSpecifications implemented with Behavior-Driven Development are:instantly readable,focused on the business goal,hiding the implementation details,encouraging reuse of test code.Behavior-Driven Development is not about tools. It’s a way of building software. We can implement specifications in any way we want, however, there are tools that can help us. {cucumber} is one of them.BDD with base RWe can practice BDD using base R. Having a set of examples of how the system should work, we need to establish a way of translating examples to code.We need to represent the business language with code – a set of actions that user of the system can take. We can do it with functions. Those functions will create the interface of the system. Their names can follow closely the natural language description of the action. They will abstract and hide the implementation details of the system. They will allow reuse of the test code.The specification of the bookstore could look like this:# tests/acceptance/test-bookstore.Rtest_that("Bookstore: Adding a book to cart", { # Given bookstore