Recently I’ve had this idea that came into my mind while working on the Sentry – let the users of my library (if there will be any) to configure not only the set of rules, connection strings, urls etc. but also the underlying providers that do all of the heavy lifting (e.g. the HttpClient responsible for communicating with the API). It means that as long as you’re not satisfied with the default solution, please feel free to provide your own engine that will for example talk to the database and perform a query on it. And that’s one part of the story, however, even the more important thing to do was to test that behavior – I had to be sure that would work. So how can we test the classes (I’m talking mostly about the integration testing), that hardly implementy any interface (pretty much none) such as the mentioned above HttpClient? Actually it turned out to be quite simple with the usage of the Wrapper pattern.
Behavior-driven development (BDD) is a process of developing the software that has evolved from the TDD (test-driven development). We can think of a BDD such as the feature driven approach to the TDD. The main advantage of the BDD over the TDD is the way the tests are being written, in a form of the story that can be understood both by the developers and the customers. In short, we can simply state that the BDD is the TDD done right – it makes use of the so called ubiquitous language which is the core part of the domain and the concepts presented by the customers (domain experts). In this text, I’ll present how you can start using the BDD approach in your code and the general idea behind that. We will start with our simple “framework” and then proceed to the MSpec (yet there are other great libraries such as the SpecsFor or NSpec and even more of them). In the examples below, I’ll be using the NUnit as the testing framework and the Moq as the mocking framework. As for the tests itself, they will be the real live examples from my open source project called Sentry.