Getting started with SpecFlow (Part 2)

This is part 2, if you've not read part 1 please do. Download source code

Quick recap

We have our solution, Dentist with one project Dentist.Specs with a single feature file called BookAnAppointment.feature.
Its now time to generate some code, if you have previously generated the steps then select the step file you created and delete it.

Part 2 - Time for code

Getting started with SpecFlow (Part 1)

This blog post will, hopefully, provide a good starting point for those interested in using SpecFlow and BDD. This example is developed using SpecFlow 1.9, MsTest and Visual Studio 2012.

I won't go into what BDD is, or try to explain the Gherkin language as used in Specflow. This will be a basic project run through to get you started with your first Specflow & BDD based projects.

This project will be based on developing a simple system for the purpose of booking appointments at a dentist, there a multiple layers to this n-tier system.

Data Layer (DataModel)

 |

Domain Layer (DomainModel)

|

Presentation Layer (UI)

Part 1 - Defining the Scenarios

In this example, we shall be using BDD to explain the behaviour of the business domain layer and not worry about the presentation layer for now (I wish to keep the example simple).

Dependency Injection (DI)

I was late to the part on Dependency Injection, or so I thought. I'd been reading and trying to get my head around IoC (Inversion of Control) for some time when I decided to delve deeper and started reading the book Dependency Injection in .Net. After reading about 50 pages it dawned on me, I'd been designing my software with DI in mind for years.


My background in strongly typed modern (at the time) C++ had always enforced reference (pointers) access via an interface (or pure virtual class) in conjunction with the pattern identified by Kevlin Henney called PFA (Parameterize From Above), complemented by my own personal hatred of the global singleton "don't know how to solve a problem so I'll just cheat" anti-pattern had made me subconsciously an advocate of DI. Like many of the GoF (Gang of Four) patterns named in the book Design Patterns : Elements of Reusable Object-Orientated Software I'd been using them for years, I just didn't know they had a name (remember all this book really did/does is allow us to talk about a pattern using the same language, the patterns are just a result of good design and are pretty obvious). Now I understood, now I could talk to my other developers using the same language.

Unit testing

If you're here, then your thinking about testing. Please visit my articles on SpecFlow for BDD to bring something new to testing.

There is lot to be said about unit testing (or testing via code), and a lot of opinions on the right and wrong way to do this. The first thing I say about code testing is that it doesn't matter how you do it or how much or how effective it is, we all need to start somewhere - just as long as you are doing some form of code testing it means your can build on it and address those areas where improvements can be made.

I follow three levels of code testing:

1. Unit testing (strict AAA)
2. Interaction testing (or integration testing)
3. System testing (as much as can be done)