Test Driven Development Conventions
Test Driven Development Convention Definition:
Understanding Test Driven Development Practices and Testing Components with ReSharper
Test Driven Development Convention Justification:
Test Driven Development (TDD), or sometimes referred to Test First Development, is the development process of defining the “What” before the “How” of Software Entities design.
Single Unit of Work Tests, Unit Testing, and Integration Testing and Testing Collections within Tests provide validation of the Concrete implementations, the “How”.
Testing Conventions ensure that the Various Responsibilities of each of these Arenas are Clearing Understood and Implemented
Test Driven Development Convention Standards:
The Two Test Assembly Arenas
Integration Tests – These tests validate collections of Single Unit of Work unit tests. Integration Tests validate the real world expectation of one or more Unit Tests.
Unit Tests – These tests focus on a Single Unit of Work. Unit Tests should validate, through mock or fake objects, code functionality without dependency requirements outside of the calling assembly. If a “Unit Test” does consume a dependency outside of the calling assembly it is technically an Integration Test.
The Modern Developer’s Test Class Pattern
The Gherkin Behavior Driven Development (BDD) syntax of “Given/When/Then” provides a way of abstracting the concrete result expectations in a Naming Convention.
The GWT syntax defines the Test Class in the “Given” statement:
The GWT syntax defines the Test Method Action in the “When” statement:
The GWT syntax defines the Test Method Expectation in the “When” statement:
The complete Method Name:
The Gherkin Naming Convention syntax may seem long but it provided an enormous value.
By abstracting the Action and Expectation of a Test Method, BEFORE the Method is even created, the Developer has a clear road map for testing the concrete code block.
Remember in TDD, the test is a Failing Red Tests first…
… The Test Method Name Defines the Action and the Return Expectation
The AAA format of Arrange/Act/Assert compliments the GWT format by separating the actual Test Method into logical sections:
Arrange – This section holds all dependency setup for the test. This section ONLY holds Dependencies that are Unique to this tes. all Dependencies that have a common use for the Class is declared as Private Property Variables and initialized in the Constructor
Act – The Act section is the call to the Method Under Test. Initially this is a Class and a Method located within the very file that the TDD test is located. After the Test goes GREEN then ReSharper is used for Move Refactoring into the Assembly proper namespace folder structure
Assert – The final AAA section “Asserts” or validates ALL Software Elements of the resulting object from the Act Section
It is Imperative that All Elements be Validated…
… A Test for Null, Error Flag, Error Collections, Return Primitive Values and Return Collection …
…… Must be Validated in Separate Asserts
The GWT Naming Convention is you Best Friend!
It give you Crystal Clear Clarity on what the Test Method success criteria.
The AAA structure is your Best Friend Companion as well!
It provides a separation of concerns for the Arrangement of Dependencies, That Action of the Method Call for a Assertable Result.
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