Unit, Integration and Acceptance Testing Conventions
Test Assembly Convention Definition:
These Conventions for the Testing Assembly will be structured to support both Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD).
The Testing Conventions create a Structured Folder format to support the Organization of Unit, Integration and Acceptance Tests Classes.
Test Assembly Convention Justification:
These Standards create a Testing Folder Structure that is Extensible and Scalable to all Solution Project Assemblies
The structure organizes the Test Classes into Single Responsibilities and created Helper Namespace Folders for common Utilities.
A Test Assembly, over its Lifecycle, will be Touched Many Times …
… The Testing Assemble Structure must be Flexible Enough to Support these Touches
Test Assembly Convention Standards:
The Conventions for the Testing Assembly will support both Acceptance Test Driven Development (ATDD) and Test Driven Development (TDD).
The Conventions support a structured format for organizing Unit, Integration and Acceptance Tests Classes.
These Standards create a Testing Folder Structure that is Extensible and Scalable to all Solution Project Assemblies.
The structure organizes the Test Classes into Single Responsibilities and created Helper namespace folders for common Utilities.
The Test Assembly Folder Structure
There are two basic formats for The Modern Developer’s Testing Project assembly:
Acceptance Test Driven Development and Test Driven Development
Test Driven Development
The only difference between the two is the existence of the “AcceptanceTests” Folder for the ATDD Feature and Steps folders for the SpecFlow files.
The ATDD Folder Structure:
The ATDD folder structure has an “AcceptanceTests” folder that holds the SpecFlow Feature and Steps files created for the Acceptance Scenarios.
The Business User Story is converted to a Feature Story and the Development Task Scenarios are the created within the Feature Files.
The Gherkin Scaffolding Code is generated from the Scenarios and placed on the computer clipboard to be pasted into the SpecFlow Steps Test file.
The SpecFlow Steps Test file holds the generated Scenario Gherkin Code and is pasted into the SpecFlow Steps file to create the initial YELLOW Inconclusive state of ATDD.
The Unit Test Folder is the Same as in Test Driven Development (TDD) Detailed in the Next Section
The TDD Folder Structure:
In ATDD and in TDD the “UnitTests” folder hold Single Unit of Work (SUW) Unit Tests and the Integration Tests.
The integration tests are generally tests that consume an external dependency or SUW’s validated code
The lower level folder structure is defined by the Single Responsibility Testing framework that represents the System Under Test (SUT).
The Unit Test Folder Structure should be an Abstraction of the Folder Generated Namespace of the System Under Test …
… You Should be able to Map the Test folders to the Assembly Folders One-To-One
The “CommonHelpers” folder should contain all Utility Helper Methods that can be implemented across multiple Test Classes.
All Test Classes follow the Single Responsibility Principle and must contain Test Methods that are related to the Test Class and defined by the “Given” Gherkin Naming Convention of the Test Class.
Helper Methods that are unique to the current Testing Class type should be encapsulated within a Page Region Section at the bottom of the Class.
The structure within the convention folders are customized to the implementing System Under Test “(SUT)” …
… They define the abstraction of the Responsibilities of the SUT
The following two tabs change content below.
I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services