-
-
Notifications
You must be signed in to change notification settings - Fork 46
Writing scenarios
xBehave.net scenarios are very similar to Cucumber scenarios.
The basic anatomy of a scenario is:
- A containing assembly
- A containing type (e.g. C# class)
- A scenario (e.g. C# method)
- Some steps (e.g. delegates defined inside a C# method)
A containing assembly contains the tests for the features or specs of your system under test. E.g. if the library you want to test is named Widgets
, you might create a library named Widgets.Features
or Widget.Specs
(see What kind of tests can I write using xBehave.net?). This is the equivalent of creating a test library using xUnit.net or NUnit.
A containing type groups your scenarios together. E.g. if one of your features is a calculator, you might create a class named CalculatorFeature
. This is the equivalent of creating a test class to contain a set of xUnit.net facts or NUnit test methods.
The name of your scenario should describe it adequately. E.g. if you want to cover the scenario of adding numbers together with your calculator then you might name the scenario Addition
.
The steps within a scenario contain the code which is executed during the scenario and typically defined using the vocabulary of Gherkin.
Let's take a look at an example.
namespace Widgets
{
public class Calculator
{
public int Add(int x, int y)
{
return x + y;
}
}
}
namespace Widgets.Features
{
using FluentAssertions;
using Xbehave;
public class CalculatorFeature
{
[Scenario]
public void Addition(int x, int y, Calculator calculator, int answer)
{
"Given the number 1"
.Given(() => x = 1);
"And the number 2"
.And(() => y = 2);
"And a calculator"
.And(() => calculator = new Calculator());
"When I add the numbers together"
.When(() => answer = calculator.Add(x, y));
"Then the answer is 3"
.Then(() => answer.Should().Be(3));
}
}
}