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.
Let’s start with our own approach to the BDD and see where it leads us. It’s rather simple, but powerful enough for the most cases. BTW kudos to Marcin, who actually influenced me to focus on the BDD quite some time ago.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
public class SpecificationAttribute : TestFixtureAttribute { } public class ThenAttribute : TestAttribute { } [Specification] public abstract class SpecificationBase { protected Exception ExceptionThrown {get; set;} protected bool ExceptionExpected {get; set;} //Arrange protected virtual void EstablishContext() { } //Act protected virtual void BecauseOf() { } protected virtual void CleanUp() { } [OneTimeSetUp] public void TestInitialize() { EstablishContext(); try { BecauseOf(); } catch (Exception exception) { if (ExceptionExpected == false) throw; ExceptionThrown = exception; } } [OneTimeTearDown] public void TestCleanup() { CleanUp(); } } |
And this would be our tests (please note that I’m doing a lot of the async work and also the async tests, which can be easily fixed by changing the methods in the SpecificationBase class to return the Task instead of the void):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 |
[Specification] public class Sentry_specs : SpecificationBase { protected ISentry Sentry { get; set; } protected SentryConfiguration SentryConfiguration { get; set; } } [Specification] public class when_initializing_without_configuration : Sentry_specs { //Arrange protected override async Task EstablishContext() { await base.EstablishContext(); ExceptionExpected = true; SentryConfiguration = null; } //Act protected override async Task BecauseOf() { await base.BecauseOf(); Sentry = new Sentry(SentryConfiguration); } //Assert [Then] public void then_exception_should_be_thrown() { ExceptionThrown.Should().BeAssignableTo<ArgumentNullException>(); ExceptionThrown.Message.Should().StartWithEquivalent("Sentry configuration has not been provided."); } } [Specification] public class when_initializing_with_configuration : Sentry_specs { protected override async Task EstablishContext() { await base.EstablishContext(); SentryConfiguration = SentryConfiguration.Create().Build(); } protected override async Task BecauseOf() { await base.BecauseOf(); Sentry = new Sentry(SentryConfiguration); } [Then] public void then_the_new_sentry_instance_should_be_created() { Sentry.Should().NotBeNull(); } } [Specification] public class when_initializing_with_the_watcher_running_single_iteration : Sentry_specs { protected Mock<IWatcher> WatcherMock { get; set; } protected override async Task EstablishContext() { await base.EstablishContext(); WatcherMock = new Mock<IWatcher>(); WatcherMock.SetupGet(x => x.Name).Returns("Watcher mock"); SentryConfiguration = SentryConfiguration .Create() .AddWatcher(WatcherMock.Object) .RunOnlyOnce() .Build(); Sentry = new Sentry(SentryConfiguration); } protected override async Task BecauseOf() { await base.BecauseOf(); await Sentry.StartAsync(); } [Then] public void then_the_watcher_execute_async_method_should_be_invoked_only_once() { WatcherMock.Verify(x => x.ExecuteAsync(), Times.Once); } } |
My guess is that you don’t even need to know what really the library that I’m working on is about (however I do encourage you to find out), yet you should be able to realize what it does just by looking at the names of the specification classes and testing methods. It’s like the story with its acceptance criterias – and that’s true, since BDD is all about identifying the behavior. Honestly, you can run such tests that are written that way and show your customer or the project owner that they all pass (hopefully) and he should be able to understand what’s going on, just by reading them out loud (or quietly). And that’s what’s all the fuss about. Once you get the general idea, let’s take a look at how we can simplify these tests with the usage of the MSpec:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 |
public class Sentry_specs : SpecificationBase { protected static ISentry Sentry { get; set; } protected static SentryConfiguration SentryConfiguration { get; set; } protected static Exception Exception { get; set; } } [Subject("Sentry initialization")] public class when_initializing_without_configuration : Sentry_specs { Establish context = () => SentryConfiguration = null; Because of = () => Exception = Catch.Exception(() => Sentry = new Sentry(SentryConfiguration)); It should_fail = () => Exception.ShouldBeOfExactType<ArgumentNullException>(); It should_have_a_specific_reason = () => Exception.Message.ShouldContain("Sentry configuration has not been provided."); } [Subject("Sentry initialization")] public class when_initializing_with_configuration : Sentry_specs { Establish context = () => SentryConfiguration = SentryConfiguration.Create().Build(); Because of = () => Sentry = new Sentry(SentryConfiguration); It should_create_the_new_sentry_instance = () => Sentry.ShouldNotBeNull(); } [Subject("Sentry execution with watcher")] public class when_running_single_iteration : Sentry_specs { static Mock<IWatcher> WatcherMock; Establish context = () => { WatcherMock = new Mock<IWatcher>(); WatcherMock.SetupGet(x => x.Name).Returns("Watcher mock"); SentryConfiguration = SentryConfiguration .Create() .AddWatcher(WatcherMock.Object) .RunOnlyOnce() .Build(); Sentry = new Sentry(SentryConfiguration); }; Because of = async () => await Sentry.StartAsync().Await().AsTask; It should_invoke_the_execute_async_method_only_once = () => WatcherMock.Verify(x => x.ExecuteAsync(), Times.Once); } |
It’s kind of a beauty, isn’t it? As long as you don’t really care about having the static properties in your tests go for the MSpec (these statics are a must, due to the usage of the delegates). Otherwise, you can use some other libraries (e.g. SpecsFor, which has also a great integration with the MVC) or stick to the custom approach (probably improved), which has been presented at the beginning of this post.
Pingback: dotnetomaniak.pl
Pingback: It’s been over a year | Piotr Gankiewicz
Pingback: Becoming a software developer – episode VII | Piotr Gankiewicz