Writing requirements is one of those things that I tend to dislike very much for one simple reason. By the time they are written they are already out of date. Furthermore you can never really tell if the software satisfies the requirements in an automated way. For that reason I'm going to use a technique where I write the specifications in a specific format called Gherkin and I'm going to use an automation tool called SpecFlow to ensure that my code satisfies the specifications. If you want the system to change in any way then I'll do it by updating the specifications and then making the code satisfy the updated specs. That way the requirements are not only documented but they are "living" which means they change in order to make the system change and the docs and code are always in sync with each other.
Create GitHub repos for the api and web ui
Being in iteration 1, we don't yet have a place to store our source code. We need to write our specs along side our source code so that the automation tools can access them. Just like before, I'm going to create a GitHub repo for the api code as well as the web ui code.
Now that I have a place to store the api and web ui code I can get started defining specifications using SpecFlow for the api.
Clone the api repo
With the api git repo created I'll clone that locally on my workstation.
git clone https://github.com/wshaddix/theharbinger.api.git
Install the SpecFlow extention
SpecFlow integrates with Visual Studio 2017 as an IDE extension. Their website has instructions on how to get started so I'm not covering that here.
Create the blank solution
To start with I'm going to create a new blank solution in Visual Studio 2017 and call it "TheHarbinger". This solution will hold the api and the api specification projects.
Create the Specs project
Next I'll create an xUnit test project named "Specs" that will hold all of our specifications for the various features that the api will implement.
Since I'm using xUnit for automated tests I also need to add a reference to SpecFlow.xUnit so that SpecFlow knows to use the xUnit test runner. In doing this you will also pull in the SpecFlow NuGet package needed to execute the specification files.
Write the health check specification
Now we can add our first specification file for health
checks. To start with I'm going to keep this as simple as I possibly can just to keep things moving along. I'll add a feature file in the
I'm only going to implement a very simple scenario to start with. I'll add on to this later but for now this will let me write the first specification and start designing the code. The specification looks like this:
Feature: HealthCheck In order to determine if the system is available As an api monitor I want to be able to query the status of the api Scenario: The api is up Given I have requested the healtcheck url When I perform an http get operation Then the result should be a status 200 is returned
Generate the step definition file
Now that I have the spec written I need to wire it up to be able to call the actual system under test via xUnit. SpecFlow will generate the template for you from any given
With the step definition file in place we have completed the analysis of the health check feature of the api. We will surely add to it but we have the initial spec written. Next we will move on to designing the api to implement the health check and refine the spec and the code until we're happy with the result.