Data points: behavior-driven design with Specflow

So far, you have become familiar with my preferences, that is, inviting developers to the user group I am hosting in Vermont to post topics of interest to me. As a result, columns have been created on topics such as Knockout.js and Breeze.js. There are more topics, such as command query segregation (CQRS), which I have studied for some time. But recently architects and testers Dennis Doire talked about Specflow and Selenium, which testers can use for behavioral-driven Development (BDD). Once again I opened my eyes and began to look for reasons to play these tools in my heart. That being said, I'm really focused on BDD. Although I am a data-driven worker, the days of my application from the database are gone and I am interested in focusing on this area.

BDD is a form of change in test-driven development (TDD) that focuses on user stories and builds logic and testing around those scenarios. You are not trying to satisfy a rule, but to satisfy multiple sets of activities. It's very holistic, and I like it, so I'm interested in this aspect. The idea is that while a typical unit test might ensure that one event for a client object works properly, BDD is concerned with the broader behavior scenario that I expected as a user when I used the system I built for me. BDD is often used during discussions with customers to define acceptance criteria. For example, when I sit in front of my computer, fill out the new customer form, and then press the Save button, the system should store the customer information and then show me a message indicating that the customer was successfully stored.

Or, perhaps, when I activate the Customer Management section of the software, that section should automatically open the most recent customers I've handled in the previous session.

As you can see from these user stories, BDD may be a UI-oriented approach for designing automated tests, but many scenarios will be written before the UI is designed. It can be automatically tested in a browser through tools such as Selenium (docs.seleniumhq.org) and Watin (watin.org). But BDD is not just a description of user interaction. To learn more about BDD Pictures, see the group discussions on InfoQ, some of the official institutions for BDD and TDD, and specification by Example on Bit.ly/10jp6ve.

I want to get away from problems like button clicks and redefine the user stories in small amounts. I can remove the UI-dependent elements from the story and focus on the parts of the process that are not dependent on the screen. Of course, I'm interested in scenarios related to data access.

It may be tedious to build the logic to test for specific behavior. One of the tools that Doire described in his presentation was Specflow (specflow.org). This tool integrates with Visual Studio to define user stories, called scenarios, through simple rules for this tool. It then automatically creates and executes some methods (some methods are tested and some methods are not tested). The goal is to validate the rules that satisfy the scenario.

I will lead you to create some behavior to arouse your interest, and if you want to learn more, you can find some resources at the end of this article.

First, you need to mount Specflow into Visual Studio, which you can do from Visual Studio's extensions and update manager. Because the point of BDD is to start the development project by describing the behavior, the first project in the solution is a test project that describes the behavior in the project. The remainder of the solution will continue from that point.

Create a new project by using the Unit test project template. The project needs to refer to TechTalk.SpecFlow.dll, and you can install the file using NuGet. Then, create a folder named Features in this project.

My first feature will be based on a user story about adding a new customer, so in the Features folder, I created another folder named Add (see Figure 1). I'll define the scenario here and let Specflow help me.

Figure 1: Test project with Features and ADD subfolders

Specflow follows a specific pattern of dependent keywords that help describe the functionality to define its behavior. These keywords come from a language called gherkin (yes, cucumbers in kimchi), all of which originate from a tool called Cucumber (Cukes.info). Some of these keywords are Given, and, when, and Then, and you can use these keywords to generate scenarios. For example, the following is a simple scenario encapsulated in the Add new Customer feature:

Given a user has entered information about a customerwhen she completes 

entering more Informationthen that customer sh Ould be stored in the system