DDD, ATDD, BDD and TDD
Do I Really Have to Do All of This?
The simple answer is NO
Most developers do not use any of the following Development Processes:
Domain Driven Design (DDD)
Acceptance Test Driven Development (ATDD)
Behavior Driven Development (BDD)
Test Driven Development (TDD)
Each of the processes above is implemented to address Business Application Development issues that have been refined for over sixty years. There has been millions of dollars invested in research to identify common failure point for Software Projects over the last six decades.
The studies have found that most projects do not meet the expectation of the Business Stakeholders. As large percentage of projects never see the light of the Production day. All the rest require the Business Owners to “Accept” what they have been given and just “Live with it”.
Ten Reasons for Enterprise Software Application Development Failures:
The Business Vision of Success is Very Different than the Solution Providers Vision
The Technology Domain does not Represent the Business Domain
The Business Acceptance Criteria Cannot be Mapped to its Development Components
Validation that the Developed Components meet the Business Acceptance Criteria
Clearly Define the “What” of the Business Acceptance Criteria prior to creating a single line of “How” development code
Interaction with the Business Stakeholders to validate that the Technology Acceptance Criteria development tasks plan meets the Business Acceptance Criteria expectations
Development time and money spent before the “What” is clearly understood by the Developer
Lack of Automated Test Assemblies to validate Development solutions support the Business Acceptance Criteria expectations
Tightly Coupled Software Elements that create “Brittle” designs that are costly to change and maintain
Naming Conventions that do not support ease of understanding for Application support over the Life Cycle of the Development efforts
As Much as 80 Cents of Every Dollar
… Spent on an Average Enterprise Application
…… Is in the Maintenance and Support of the Deployed Business Solution
The Benefits of the Alphabet Development Processes
It is NOT necessary or required to use all of the Alphabet processes in every development situation.
Each one of the above processes has a reason for use. Each of the processes would seem to complicate the traditional development process.
In the book Code Complete 2, Steve McConnell states:
“Software’s Primary Technical Imperative is Managing Complexity”
This statement is not meant to imply that your imperative is simple software: It meant to make sure that any complexity introduced into your software solution has a valid “Business and Development Purpose”.
Each of the processes above is defined and their use described below. The definition will state the process and the description will define its use.
Each of the four process descriptions include the following information:
Who primarily Benefits from the implementation of this process
What this process provides to the Business solution
Where to use this process in the Software Development Life Cycle (SDLC)
When to use this process
Why it is important to the Business Stakeholders
The only process that should be considered as mandatory is a variation of the TDD Process
It does not have to be the “Pure” implementation of TDD
There should be some Environmentally Sensitive Culture Variation of the TDD Process
The Alphabet Development Processes
The use of ATDD, BDD and TDD to implement the Domain Entity Model created in DDD.
Acceptance Test Driven Development is a Vertical Development representation of the TDD Horizontal Development process.
The Test Driven Development process is an iterative three stage process that starts with a RED test as an abstraction of the intent of the “To Be Developed” code.
This code then moves to the concrete validation GREEN test.
The final YELLOW stage refactors the test assembly representation of the concrete code into the best practices Design Principles and Code Standards.
This process is then repeated for all the required Methods Under Test.
One of the biggest advantages of TDD for both Unit and Integration tests is that the tests actually become “Templates” for the implementation by “Higher Level Modules”
Domain Driven Design (DDD)
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.
Acceptance Test Driven Development(ATDD)
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
Behavior Driven Development(BDD)
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.
Test Driven Development(TDD)
Everyone benefits from Test Driven Development.
Here are a few of the major benefits that TDD provides
- The Client’s Business Stakeholders – Create a bridge to Acceptance Test Driven Development and Behavior Driven Development
- 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
- 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
- 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
- Quality Assurance Team – The Test Suites become the road map for the QA Testing harnesses.
- 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
- HAPPY PATH – These are the tests that validate functionality when all dependencies and method parameters are valid
- 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
- GIVEN – The Name of the Nested Test Class inside the Test Class Wrapper
- WHEN – The Action Declaration of the Method Name
- THEN – The Assertion on the Method Results
Examples of the Testing Standards:
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:
- 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
- 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.
- 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.
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
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.
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.
The Primary Business and Development Motivations for Implementation of these Processes:
- Delivery of Business Solutions that Meet Initial Perceived Expectations
- A Lower Total Cost of Ownership (TCO) of the Business Solution over the Lifetime of the Deployment
- Faster Time to Market of New Features and Functionality due to Automated Integration Test Suites
- Lower Development Costs for Change Requests due to Business Domain and Technology Domain congruence
- Shorter Developer Ramp-up Time for Understanding of the Software Intent due to Automated Unit Test Suites
- Standardized Testing Patterns and Software Entity Naming Conventions that Define the Software Intent without Concrete Understanding of the Developed Code Base
Wisdom Pearl #107: Technical Insanity
Applying the Same Failing Process Over and Over
… Expecting a Different Result