result = view.GetData(
Telling the service layer, about the exception handling behavior (ActionPolicy is injected into the decorators):
var policy = ActionPolicy
Using these approaches has immensely reduced code duplication, made the codebase more stable and flexible. Additionally, it made everything more simple, due to the logical encapsulation of complex details.
When I started to look at BDD I investigated all the frameworks out there (for .net) and ended up using none of them. Main reason is I feel like the community hasn't settled on a syntax and best practises yet so instead I continued to use NUnit with a base class based on a blog post by Ben Scheirman. This worked out really well because BDD is not about the tooling but making the tests clean and understandable which is totally possible with normal tools like nunit.
Compared to my old unit tests the new style is much more readable and puts a lot more focus on naming and behavior. We're not that far from printing out the method names and have a discussion with the business people about the system.
public class WhenAddingLineItemToEmptyOrder : BDDBase
public void Arrange()
order = new Order();
public void Act() // called by BDDBase
LintItem item = new LineItem();
item.Quantity = 1;
item.Price = 10;
public void TotalPriceShouldBeUpdated()
public void OrderCanBeCheckedOut()