PLEASE FOLLOW THESE INSTRUCTIONS – thanks 🙂

1 – Select the Download link below or Downloadthe ZIP file from here

2 – If you get the prompt: “Zip is Not Commonly Download” please use Pull Down selection: “Keep” – It is Safe

3 – Locate the zip in your download folder and move to a new folder named “Interface Inheritance” or a name of your choice

4 – Expand the ZIP into the newly created folder

5 – Select the solution file: InterfaceExtensions.sln and open in VS2012

6 – Compile the solution

7 – Run the Test Runner to validate functionality of all of the components

If you have ReSharper, its test runner will appear when you open the solution. If you don’t have ReSharper you can download a free 30 day trial version. I strongly recommend doing so. 

If not, the VS2102 test runner will work: Cnt +T,R,A 0r Menu – Test- Run – All Tests

The VS 2012 Solution Code for IData Extension Demonstration

The IData Business User Story will define the high level desirement of the development request. It is designed to be a structured, simple statement that can be understood by all parties.

Here is the Business User Story for the IData Extension Demonstration:

As a Modern Developer

I want to Create Data Collections from Different Data Sources Using Interface Inheritance

So that I can use a Single Data Class Type to Extend My Data Sources through Behavior Not Class Inheritance

It is essential that all parties understand and visualize the same goal. The User Story defines the High Level but the details need to be seen the same by all. The Ubiquitous Language, the Lexicon of Terms, helps to communicate the same ideas to all concerned at a Lower Level.

Here is the Ubiquitous Language as the Lexicon of Terms for the IData Extension Demonstration:

1) ExtendingInterfaces – The Namespace that acts as the container for all of the IData Interface Extension example Software Entities

2) Stub Data Collection – A Data Transfer Object (DTO) Fake Stub Data Collection that is used in demonstrate Repeatable data for Unit Testing

3) Services Data Collection – A Data Transfer Object (DTO) Fake Data Collection that is used in demonstrate Service Call Data

4) StubData Object – A Class that implement the IData Interface for Unit Test data and consumes the IData Extension Methods defined by the ExtendingInterfaces.StubData Namespace

5) ServicesData Object – A Class that implement the IData Interface for Real-time data and consumes the IData Extension Methods defined by the ExtendingInterfaces.ServicesData Namespace

6) IData – A Generic Interface that defines as a Data DTO Request Type and a Data DTO Response Type signatures for implementation is the Concretes Data Types: StubData and ServicesData. This is the Interface being extended with the behavior Extension Methods

7) Error Object – A DTO that holds the State of an Error. It contains three primitive type Properties: Message, StackTrace and a Boolean Success flag. This DTO is a member of the List Property in the ErrorCommon Class

8) RequestCommon Class – The Class that contains common behaviors for managing Error and Exception Handling.

9) Unit Test – A Test Pattern that validates a Single Unit of Work. These tests are repeatable Today, Tomorrow, Next Week and Next Year with specifically defined Stub Data

10) Integration Test – A Test Pattern that validates Run-time operation. These tests are not guaranteed to be repeatable specifically Data. These test validate general required functionality without the need for specific data results

11) Interface Inheritance – An Object Oriented Programming (OOP) inheritance model that creates a “Behaves Like” relationship with the implementing C# Type: Class or Struct

12) Class Inheritance – An Object Oriented Programming (OOP) inheritance model that creates a “Is A” relationship with the derived C# Class Type

13) The GetData () Method – The Contract Signature within the IData Interface that must be implemented in the StubData and ServicesData Concrete Class Types. This method is used to get the Data for the requesting Client Module: Stub, Xml or Services Data

14) IData Extension Methods – These Methods with extend behavior to the IData interface. These Extension Methods will create a Common Error handling mechanism for managing Conditional Error Checks and Exception Error Handling

15) ATDD Testing – Acceptance Test Driven Development maps User Story Acceptance Criteria to real tests using a language called Gherkin

16) The Gherkin Language – A BDD language that defines Tests in a Given / When / Then syntax structure. This structure clearly defines what you want to test GIVEN a defined context When a scenario is present and Then the results expected

17) TDD Testing – Test Driven Development demands that all Concrete code be written within the Test Assembly first to comply with the Test signature created as a RED Test from the BDD Scenarios. The code is then Refactored to the Project Assembly after the Tests have been certified as GREEN passing code tests./span>

18) Xml Data Collection – A Data Transfer Object (DTO) Fake Data Collection that is used in demonstrate Xml Data

19) XmlData Object – A Class that implement the IData Interface for Unit Test data and consumes the IData Extension Methods defined by the ExtendingInterfaces.XmlData Namespace

20) Stub Data Flag – An app.config setting that turns On or Off the ability to use Stub Data Inheritance. This demonstrates a simple solution the feature that prevents Stub Data from creeping into an Enterprise Production Releases.

21) Subscriber Info Request and Response DTOs – Composite DTOs that encapsulate the Requests and Responses for Subscriber Data. These Complex DTOs carry Base Classes for Common Data in the Request and Error Handling in the Response. The Subscriber Id and Stub Data Flag for the Request and Subscriber Data and Error Handling in the Response are managed by these DTOs.

The Business User Story defines the “WHAT” of a development request at a very high level. In order for a development team to understand the “Definition of Success”, the “HOW“, of the request the User Story must have defined Acceptance Criteria. This criteria is mapped to actual development tasks during the Acceptance Test Driven Development (ATDD) process.

Here are the Acceptance Criteria for the IData Extension Demonstration:

1. Create the Stub Data Collection from Namespace Interface Inheritance with Stub Data Flag True

1. Create the Stub Data Collection from Namespace Interface Inheritance with Stub Data Flag False

1. Create the Fake Service Data Collection from Namespace Interface Inheritance

1. Create the Fake Xml Data Collection from Namespace Interface Inheritance

1. Display the Interface Inheritance Collections in a Console Application with Stub Data Flag True

1. Display the Interface Inheritance Collections in a Console Application with Stub Data Flag False

There are two types of development projects: Greenfield and BrownField.

–  A Greenfield project is a new project that has no inherent restrictions based on previous development

–  A Brownfield project is a Legacy project that has an inherent structure that must be taken into consideration when adding new features and functionality

The IData Extension project is a Greenfield project so we can define the architecture from scratch.

Here is the solution assembly file structure for our IData Extension Demonstration Project:

1 – The ExtendingInterfaces Assembly Structure

2 – The ExtendingInterfaces Console Application Folder Structure

3 – The ExtendingInterfaces.SubscriberDAL Folder Structure

– The ExtendingInterfaces DAL Class Structure

4 – The ExtendingInterfaces.SubscriberDAL.Tests Folder Structure

The IData Interface Extension Demonstration also demonstrates how to use SpecFlow for Acceptance Test Driven Development (ATDD) to create Scenarios as Behavior Driven Development (BDD) test code in the Gherkin language.

The Business User Story is Used to Create the SpecFlow Feature Story

Compare the Business User Story to the ATDD Feature Story

This BDD “Feature Story” is used to create the roadmap for developing the Feature Scenarios. Development tasks are created from the implementation of the auto-generated Gherkin Code within the Test assembly using Test Driven Development (TDD).

The YELLOW ATDD Tests are available for viewing on Website pages for validation of the planned development tasks BEFORE a single dollar is committed for development.

All concerned parties can ensure that the Intent of the development request has been understood correctly

Below is the SpecFlow Feature file with its Scenarios and the ReSharper Test runner with the result of the Gherkin YELLOW Test code. These tests are marked “Inconclusive” as they represent the abstractions for development.

Interface Inheritance ATDD SpecFlow Feature File

The SpecFlow Steps File is the actual code that is run as Acceptance Tests in ATDD. The code is generated within the Feature File.

The Generated Code is pasted into C# Regions inside the Steps file that is the actual Test Assembly code

The Gherkin naming convention of: Given/When/Then (GWT) is encapsulated inside the regions. The regions map one-to-one to the Scenarios defined inside the SpecFlow Feature file.

The IData SpecFlow Steps File using Regions to Encapsulate Scenarios mapped to the Feature File Scenarios.

The Acceptance Test Driven Development process creates YELLOW tests as the first step of ATDD. These tests appear in the test runner as “Ignored”. The tests will define the results as “Inconclusive” as no implementation has been developed.

The first stage is where the Business Stakeholders, Product Owners, Architects, QA Team Members and Subject Matter Experts “Certify”, by viewing an auto-generated test result Website page, that the displayed tests, defining the Roadmap, is indeed the representation of the Business Request.

SpecFlow Generates Web pages with Detail Information and Status of the ATDD Process

Below are is an example of the Gherkin code in the Test Assembly and the results as Ignored or Inconclusive in the Test Runner:

– The IData SpecFlow Steps File YELLOW Inconclusive Test

– The IData Test Runner SpecFlow YELLOW Inconclusive Tests

After the interested parties “Certify” that the development abstractions of intent comply with their request the ATDD YELLOW Tests are moved to the RED Test stage. This will display on the auto-generated Website pages as “Failing” tests.

The RED Status of the ATDD Test will inform all Interested Parties that Development Implementation is Forthcoming

The auto-generated Method: ScenarioContext.Current.Pending() inside the Gherkin generated test method is replaced with an Arrange/Act/Assert (AAA) Test Method implementation structure that asserts that IsNotNull == null: A False or Failing Test condition.

The AAA Test Method Format for RED Tests

In TDD the First Test is Always a RED Test

This creates a visual reminder that the Concrete Implementation of this test had not been written yet. The test is a simple True == False type of Assertion within the Unit Test AAA format: Arrange / Act / Assert.

You can Assert a string is equal to null after an explicit initialization of the string variable is set to ‘null’ in the Act section of the AAA format.

The RED Unit Test to indicate the Code has not been completed

The next step in TDD is to create the concrete code that will move the RED failing test to GREEN. This is the actual assembly system code but it is first created and validated within the Test Assembly. This is the difference between conventional Unit Tests and Test Driven Development.

All Concrete Code Implementations are Created FIRST in the Test Assemble as a Passing GREEN Test

The Modern Developer is a “Subtractive Developer”.

A subtractive developer creates the initial GREEN Test code to pass, quite possible not using all best practices. Here are some examples:

1. Temp Variables may be used to Validate State in a Debug mode using Intellisense
2. Conditionals can have Violations to the Single Responsibility Principle
3. Candidates for Method Extractions can be left in the initial GREEN test implementation code
4. The var keyword can be bypassed to better define Types if required during this stage
5. Dependency Classes can be nested for validation of required functionality
6. Candidates for Private Helper Methods can remain within the testable code
7. Candidates for Public Utility Helper Methods can remain within the testable code
8. Class Extension Method Candidates can remain within the testable code
9. Interfaces can be deferred until the YELLOW Refactoring stage

A Subtractive Developers gets the initial GREEN Test to Pass with the understanding that Best Practice Refactoring is the YELLOW Step Not the GREEN Step

This paradigm allows the developer to iterate through a number of possibilities before committing Best Practice effort to the GREEN Test

A Move Refactoring is used to place the passing code to the System Under Test (SUT). This process ensures that all code is functioning as defined in the “What” abstraction Before it is committed to the “How” Assemble System Namespace implementation.

The GREEN Unit Test to indicate the Code has been completed and Functional in the Test Assembly

The YELLOW Refactor Step moves the Subtractive Development code into the final deliverable state.

The subtractive developed code is Refactored to a YELLOW TDD stage. The code will now comply with all Best Practices that apply to the GREEN code.

Here are some Refactoring examples:

1. Temp Variables are removed and the value placed in the Single Usage Statement
2. String Concatenations are Replace with String.Format
3. Single Responsibility Principle is used to create Private Helper Methods for Conditionals
4. Candidates for Method Extractions are moved the Helper Region Section of the Class
5. The var keyword replaced explicate Typing when the right side of the declaration defines the Type
6. Dependency Classes are refactored into their own files
7. All Candidates for Private Helper Methods are moved the Helper Region Section of the Class
8. Candidates for Public Utility Helper Methods are moved to Public Utility
9. Class Extension Method Candidates are moved to Extension Classes
10. Interfaces are created and implemented as required

A Tool like ReSharper is Used to do Move Refactoring to the System Under Test Namespace Folder Structure for the Dependencies of the YELLOW Test

The Refactored Test Concrete Implementation Code

A Tool like ReSharper is used to do Move Refactoring

This refactoring will move the YELLOW code from the Test Assembly and into the final System Under Test Assembly Namespaces.

The tool will set the correct Folder-centric Namespace Schema and move all required References. The code will function identically in the SUT as it did in the YELLOW Test Assemble.

ATDD Tests are all INTEGRATION Tests, not UNIT TESTS. They don’t test a Single Unit of Work; they test the call as a Client that consumes one or more Dependencies of a Method under test.

ATDD Tests are the “Vertical” Representation of the Highest Level Abstraction “Horizontal” Unit Test

This means that all test code for the ATDD Scenario Gherkin formatted Test Assembly code has already been created and validated within TDD.

BDD Green tests use copied code from the relevant TDD Test to comply with the Gherkin Given/When/Then (GWT) Tests structure as defined in the SpecFlow Feature file. This code is pasted in the Steps code file within the appropriate sections. 

The IData SpecFlow Steps File GREEN Test

The last test step in our process is to validate that all ATDD and TDD Tests run GREEN.

This ensures that all development defined by the Business User Story and the ATDD SpecFlow Acceptance criteria scenarios are completed.

The Test Runner validates that all the Horizontal ATDD Tests and the Vertical TDD Tests are running GREEN .

SpecFlow Website will display the completed status of the deliverables.

All Tests MUST Run Green Today, Tomorrow, Next Week, Next Month and Next Year

The GREEN ATDD Tests

All GREEN Test Runner Tests 

SpecFlow can display the Test Reports in an HTML format for all Business Stake Holders and Development Team Members to view.

The Final GREEN Tests Status will be reflected in the SpecFlow Reports

The IData SpecFlow Test Runner GREEN Test

The Modern Developer must assure the quality and performance of their work. All Unit and Integration tests within the Test Assemble Suite must pass.

In addition to the Test Suite validation, the deliverable must perform within the Application according to the Acceptance Criteria of the Business User Story that have been validated in the ATDD Test Suite Scenarios.

Once the Developer has “Certified” their work, passing it to the Quality Assurance Team is the Next Step

It Is the Modern Developer’s Responsibility to Minimize the possibility of Defects found by the QA Team though an Intense QA Process of their own

The Console Display using the IData Stub Data Implementing Extension Type Enabled

The Console Display using the IData Stub Data Implementing Extension Type Disabled

This step seems self evident but you would not believe how many times in my career that key team members did not receive notifications of a deliverable that they were dependant on for their success.

A formal notification process must be implemented that communicates information for all of the Workflow steps in the Development process.

Most Agile tools and Project Management applications support notification, if configured properly.

Ensure that All Team Members Receive the Notifications They Require

This last section is meant to be humorous but there is a serious side to the thought. There are many kinds of “Bonuses” or “Rewards“ for a job well done besides a monetary reward.

A List of Common Rewards:

1. Money – A monetary reward given as an incentive for similar future results
2. Recognition – Public acknowledgement of a job well done to peers and supervisors
3. Advancement – Promotion with greater responsibilities and prestige
4. Training – Company funded advancement of your career education
5. Time Off – Paid time off to spend with your friends and family
6. New Work Structure – A new work structure such as a four ten hour day work week enabling you to spend more time with your friends and family
7. Working Remotely – A schedule that allows you to work from home a set number of days a week when possible

Rewards are Earned by Successes …

… Success is the Catalyst for Reward

…… Seek a Reward that has a Lasting Benefit to You and Your Benefactor

The Modern Developer knows that the primary imperative of the Technologist Professional is mastering their Art. A career monetary compensation change occurs with successful advancement of the Science of their chosen Technology platforms through a viable result realized by a paying Client.