The Solution Provider benefits by using a road map for success driven by Technology Architecture Designs and the Business Requirements are better understand by all parties.

When the Business Owners referer to a Business Term or Concept that term maps directly to Architecture Entities that Architects, Designers, Product Owners, Scrum Masters, Subject Matter Experts, Developers and Quality Assurance Team Members are understood in the same way.

Complex data relationships require mappings to Business Object concepts that are not currently organized in a Business paradigm within the current data model.

An Object Relational Mapping (ORM) framework such as Entity Framework can transform the database-centric data model paradigm to a Domain Driven Entity paradigm. The ORM can then adapt the disconnected data model to a Domain Entity model that maps directly to the Business requirements

If your solution has become unmanageable, and it seems like you are trying to get your arms around an Elephant that you cannot see, then a DDD approach can be of benefit as a refactoring of the current Architecture.

New Entities and their related Value Objects can be added and implemented through the Object Oriented Programming design pillar: Encapsulation.

Domain Entities are Software Objects that encapsulate their dependencies as aggregate Value Objects related the Domain Entity.

New Domain Entities can be added to the Domain Model with minimal affect on existing Entities.

With the other Alphabet processes in place regressive testing is automated and easily managed.

The major benefactors from ATDD are the Business Stakeholders and the Solution Provider’s Sales and Delivery force.

ATDD ensures that the perceptions of success in the minds of the Client are the same as the Development and Delivery team vision.

ATDD uses the DDD common communication protocol: The Ubiquitous Language.

This “Lexicon of Terms” a common spoken and written language understood the same by all team members: Client and Solution Provider.

Acceptance Test Driven Development is the process of putting “Teeth” into the Business User Stories acceptance criteria.

This process creates concrete validation that demonstrate that acceptance criteria were actually completed as expected.

Agile Tools like Rally and Project management tools like MS Project can “Track” the reported progress of developing the designs that are created to meet the User Story acceptance criteria.

By themselves they do not possess a vehicle to validate that the expected results were really ever achieved. They are just “Words on a Document”.

With tools like Rally and ATDD the “Missing Link” is in place to guarantee that the Developed scenarios meet the expectations of the Business Stakeholders.

The ATDD Process should implement at the “Highest Abstraction Level of a Solution”. It is an Integration Testing Process that validates that all lower level modules and dependencies are correctly functioning.

In an MVC Design pattern Web Application the ATDD Acceptance scenario test would validation all the CONTROLLER Methods are delivering a Composite State Model Data Transfer Object (DTO) that can support all the User Interface requirements within the Web page View.

ATDD would also validate the Request Data from a View is processed correctly and the results delivered to the View.

ATDD can be used to validate User Interfaces directly with integrated tools such as WatiN Browser Testing frameworks.

In a Middle Tier Solution ATDD should be at the Web Services of Business Logic Top Layer abstraction.

ATDD should validate that all Client services calls, Application and Services, meet the design scenario expectations defined in the Epic and Child User stories.  

When ATDD is used with a Behavior Driven Development (BDD) tool such as SpecFlow the Integration Tests creates Web Reports that can validate understanding of the User Story Acceptance criteria and the Development scenarios use to define the development tasks.

ATDD can use the YELLOW tests of BDD to have the engaged Business Owner certify that the acceptance criteria understanding of the Architect and Development team is the same as the Business Stakeholders.

ATDD creates YELLOW tests that define the “What” of the development process before any code is written. This will lower the cost of development by minimizing the misunderstandings of the User Story Acceptance criteria.

The RED tests of ATDD gives the Stakeholders a progress report that they can view on a common Browser.

GREEN ATDD tests display the completed Integration status as development milestones

The major benefactors from BDD are the Business Stakeholders, Solution Provider’s Architect and Design Team. The Developers benefit by much less ambiguity in the development environment.

If ATDD is implemented without a BDD tool, such as SpecFlow or MSpec, then the ATDD tests are really TDD tests.

The ATDD tests are created by the Developers based on their understanding of the requirements and not defined by the Acceptance Criteria of the Business Case User Story.

Behavior Driven Development is a process that is injected between TDD and ATDD to create a better understanding of the desires of the Business Stakeholders.

A Business User Story is created and a list of Business-centric Acceptance Success Criteria is defined. These acceptance criteria items are mapped to BDD Test Scenarios in the BDD Testing tool.

BDD creates a Development environment where the Architect team works with the Business Stakeholders to develop the YELLOW, inconclusive, BDD Development Integration tests from the Acceptance Criteria that can be certified by the Client as an understanding of intent of the Business case.

These YELLOW tests are made to FAIL, displayed as RED tests. This acts as a type of “TO DO” list for the developers.

These tests also act as a check list for the Business Stakeholders and Solution Provider Team Members as to what elements of the Acceptance Criteria have been completed when the tests are displayed as GREEN.

The current status can be viewed in a Browser at anytime during the development process.

The Integration Tests used to validate the Business User Story Acceptance Criteria are the ATDD Vertical implementation of the TDD Horizontal YELLOW refactored tests.

Only the GIVEN/WHEN/THEN format is used as a refactor of the fully functional AAA formatted Integration Tests.

No New Tests Are Created For ATDD using BDD!

In an MVC application they test Controller methods. In a Services layer solution they test the Web Service or class library Business Layer methods.

BDD should be considered when Business User Stories are created and the Business Stakeholders are engaged in the Business Solution process. Behavior Driven Development should also be considered if the Solution is a mid to large size project with many developers on many teams.

BDD allows the Business requirements to be better understood Before, During and After the development tasks.

The entire team benefits from the ability to “Eat the Elephant One Sandwich at a Time”.

It allows for larger complication requirements to be cut into digestible pieces.

This is the process that allows the Client’s Business Stakeholders to be in control of the Success factors of the Business Case.

When the Client’s Business Stakeholders accepts the responsibility of creating the User Stories and their expectations through the Acceptance Criteria, Behavior Driven Development allows them to validate the YELLOW tests as an accurate representation of their expectations.

The process creates an environment where they are an interactive team member representing the Client and driving the road map for success.

It gives the Client a better chance of delivering a solution that meets the expectations of the Client’s Senior Management.

Everyone benefits from Test Driven Development.

Here are a few of the major benefits that TDD provides

1. The Client’s Business Stakeholders – Create a bridge to Acceptance Test Driven Development and Behavior Driven Development
2. The Architects and Designers – Maps the Concrete Development code to automated Unit and Integration tests that are used to validate the Acceptance Criteria in the ATDD and BDD process
3. The Developers – TDD defines the “What” before any of the “How” code is written. This gives the Developer a clear understanding of the task they have been assigned to complete
4. The Product Owner and Scrum Master – The current status of the RED, GREEN and YELLOW refactoring create a dynamic status of all development that can be validated with an automated run of the Testing Assemblies
5. Quality Assurance Team – The Test Suites become the road map for the QA Testing harnesses.
6. The Client – Fewer bugs and a faster Time to Market for the initial deployment. TDD creates a maintenance environment that is far less brittle as the Testing Suites can detect regressive issues caused by New features and functionality change requests

The TDD process ensures that all Behavior Methods, and the State Data Objects (DTOs) that they consume, return the expected results. If any dependency adversely affects the Software Entity in later development, the Test Suite will quickly laser into the issue for the developer to remedy.

Test Driven Development states that the Developer creates the State Object DTOs, Classes and populates their behavior Methods inside the Test Assembly from the Unit and Integration Tests first.

There are two types of tests in TDD; Happy Path and Sad Path

1. HAPPY PATH – These are the tests that validate functionality when all dependencies and method parameters are valid
2. SAD PATH – These are tests that validate that the Error and Exception Handling are functioning  correctly. These test will also verify if you have written “Testable Code”. If you can not create a Sad Path then you need to refactor you design to support TDD.

A RED test is created using the Gherkin naming convention: Given, When, Then (GWT). This convention is used to define the intent of the code before the concrete implementations are created.

A RED test is a signature abstraction of the expectation of the Method under test. It describes the intent of the GREEN test concrete code BEFORE the code is created.

The RED Test acts as a “TO DO” list.

The RED Test designates that the abstraction signature does not have a concrete implementation at this time.

The GWT Format: Test Class Wrapper: CustomerClassTest

1. GIVEN – The Name of the Nested Test Class inside the Test Class Wrapper
    
   1. “GivenIWantToTestTheCustomerClass”
2. WHEN – The Action Declaration of the Method Name
   1. “WhenICallTheGetCustomerInfoMethod_”
3. THEN – The Assertion on the Method Results
   1. “_ThenICanValidateTheCustomerInfoObject”

Examples of the Testing Standards:

• Test Class Pattern
• Happy Test Method
• Sad Test Method

The AAA Test format: Arrange, Act, Assert is used for the concrete test. It creates a format standard that is easy to understand the Dependencies and Single Responsibility of the Test Method.

The AAA Format:

1. ARRANGE – Create all Test-centric Dependencies. All Test Class-centric dependencies are Class level Private Properties that are initialized in the Class Parameterless constructor. Any Dependency that is used in more than one test is a Class level dependency. If there are only Class level dependencies this section is Empty But Never Removed
2. ACT – A single line of code that calls the GIVEN stated method and uses the return variable naming convention of “result” for the Assertion return object. It is important to follow this naming convention standard as it will allow for easy duplication of tests for variations on a theme and for “Sad Path” exception and error handling tests.
3. ASSERT – These are multiple assertions that test ALL of the expected objects within the “result” variable. There should be Null Reference Checks along with all Error Object and Collection Asserts

All concrete code is written to PASS the test in any reasonable fashion. It is a valid process to violate Design Principles and some Code Standards during the RED to GREEN TDD stage.

Be a “Subtractive” Developer. Get the RED test to go GREEN the quickest way possible. You will gain the knowledge for refactoring as the concrete code evolves.

You can create temp variables, nested loops, extended if statements and fat methods that violate the Single Responsibility Principle and Open Closed Principle to get the tests to PASS.

Once the tests go through the RED, a failing test, and GREEN, the passing test, then a “Move Refactoring” action relocates the code to its destination: The System Under Test (SUT).

The move refactoring assigns all the required References and Namespace within the SUT correctly.

The tests are run again in their raw but functioning state to validate the move refactoring.

The Code is then Refactored

The YELLOW Stage of TDD refactors the moved code into best practice Design Principles and Code Standards.

This action will remove all the code smells created during the GREEN stage.

The YELLOW refactoring stage creates code in the SUT that will pass a Code Review.

The TDD process turns the normal development paradigm on its head. It is 180 degrees out of the “Normal” process.

It takes some time for most developers to acclimate to this new paradigm.

At all levels of Code Development.

Many of the critics of TDD state that it takes longer and cost more to mandate TDD.

Experience has shown that when the process is implemented completely and correctly that the cost and time of development can be less than 50% of the “Traditional” development process.

This reduction is attributed to engaging in development efforts when a clear understanding of the Business Case intent of the code is understood.

This prevents duplication of efforts by other developers and minimizes “throw away code” that is created when a misunderstanding of intent leads to nonfunctional results.

The bug count is seriously reduced due to the implementation and validation of Happy and Sad test cases.

Error management of conditional code statements and exception handling is validated through the Sad Tests and then confirmed at the Code Review.

Test Driven Development should be implemented at the beginning of a “Green Field”, a new project, and for all legacy “Brown Field” projects.

A legacy project that has new requirements or feature functionality enhancements should use TDD as its development methodology to bring all the value added features of TDD to the new code base.

All change requests for an existing project should use TDD to prevent being “Part of the Problem” in a non-compliant Code base.

Refactoring of Critical Business Entities can benefit from TDD YELLOW refactoring.

Existing “Code Smells“, code that is not compliant with the Design Principles and Code Standards, can be refactored into TDD.

This “Back Log” task process of legacy system can bring code into compliance over the Life Cycle of the deployed solution

When ATDD is used with BDD it creates the “Vertical” representation of the Development Process. TDD creates the BRIDGE that links the concrete development of the “Horizontal” representation of the Development process.

All Integration Tests in ATDD that validate the User Story Acceptance Criteria are refactored and reformatted representations of validated Horizontal code.

No New Test Code is created to validate the User Story Acceptance Criteria.

All The ATDD and BDD code is developed and validated in TDD.

This code is used to create the ATDD GREEN Tests for display in a Browser for the entire engagement team to validate compliance with the Business objectives.

TDD code refactored into the ATDD GREEN tests are the Client’s validation that the defined Business expectations have been met.