Introduction

The purpose of this repository is to document examples of unit testing across multiple languages and libraries.

Criteria

The examples - across different languages and libraries - will be structured similarly so as to be easily discernable by developer's who may not be familiar but are interested in common practice for testing within a particular programming language.

As such, it is the intent of each example to demonstrate writing unit tests for the following Acceptance Criteria. The following provides User Stories, with defined criteria and scenarios to be addressed in each programming language (+library) example:

User Story: Access

As an administrator
I want to access all user accounts
So that I view each user information

###Criteria

• Can access all user accounts
• Can access properties of each user account

###Scenario: User accounts are accessible to Admin

Given I am an administrator
When I request all user accounts
Then The Session model is updated with receieved User models

###Scenario: User account is accessible to Admin

Given I am an administrator
And User accounts are available on the Session model
When I access a User from the list
Then I can view that User's account details

User story: Add User

As an administrator
I want to add a new user
So that I can manage the addition of accounts

###Criteria

• Can add a new user account if id is unique
• Cannot add a new user if id is already in system

###Scenario: User account with unique id added

Given I am an administrator
When I request to add a user
And The user id is not available in the system
Then The Session model is updated with the User account added

###Scenario: User with non-unique id not added

Given I am an administrator
When I request to add a user
And The user id is already existant in the system
Then The Session model is unaffected

Syntax & Structure

It is preferrable to structure tests using a Behaviour-Driven-Development (BDD) methodology - at least syntax-wise. Though unit tests focused on particular output of a single method based on varying input may be required, it is recommended to setup a test to prove a scenario of a feature. Typically this means:

• Givens are defined at the top of a test case
• Whens are descibed in set-up
• Thens are expectations within each test

That is a loose rule from which there may be variants based on the test, but generally how tests should be structured. Following such a format allows for developers to easily read and ascertain the feature and scenarios under the test.