Test First Development - Part 1

 

Test first development, also known as Test Driven Development (TDD) is a development style in which you write the unit tests before you write the code to test.   The advantage of test driven development is, that you force yourself to think about how the unit (the component) is going to work. In other words, you force yourself to think about the contract of its interface. Actually, the asserts in the unit test specify the contract of the unit.  

Sometimes, when writing a unit test after you have implemented some component, you realize that it is hard to test. You may then decide to make some design changes to the code, to make it easier to test. During test driven development (TDD) you force yourself to think about both the contract (as mentioned above), and the testability of the component, before you start implementing it. This way you may naturally design components that are easier to test, rather than having to redesign them later.

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards. Test-driven development is related to the test-first programming concepts of extreme programming, begun in 1999, but more recently has created more general interest in its own right.

 

 

Introduction to Test-First Development

 

 

 

 

 

 

 

Demo: Ye Old Way Developer's Tested

 

 

 

 

 

 

 

Note:  Here developer has to create test cases for scenario passing and without passing the Bark parameters of Dog class.

 

 

 

 

 

 

 

 

 

 

 

Unit Testing Frameworks

 

 

 

 

 

 

 

 

 

 

 

Demo of Unit Tests in VS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Demo of Test-First development

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Instead we have to write test cases to ensure the functionality of business suggests

 

 

 

 

Writing Unit Tests Part I

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

The First Failing Test

 

 

 

 

 

 

 

 

 

Making The First Test Pass

 

 

 

 

 

 

 

 

The Second Test

 

 

 

 

 

 

 

 

 

Refactoring a Third Test

 

 

 

 

 

 

 

 

 

 

 

Writing Unit Tests II

 

 

 

 

 

 

 

 

 

 

 

 

Note:  “Object 1” is referring Method A which calls another object “object 3” but still this Unit test

 

 

 

Note:  “Object 1” is referring Method A which calls another Data base, so it become Integration Test. We can very write Integration Test with Unit Test framework.

 

 

 

 

 

 

 

Final Project Organization

 

 

 

NUnit Artifacts

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Introduction to Refactoring

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Creation of Interface

 

 

 

 

 

 

 

 

Creation of BaseClass

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Driving Design with Unit Tests

 

 

 

 

 

 

 

Note:  If you change the existing QC passed code, Test Driven Development process will cover up your existing code by indicating RED signal.

 

 

 

 

 

 

 

 

 

 

Problem with HTTP Context

 

 

 

 

 

Decoupling the HttpContext Dependency

 

 

 

 

 

 

 

 

 

 

 

 

 

Other Design Benefits

 

 

 

 

 

 

 

 

 

 

 

Isolating Code

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Introducing the Application

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Demo: First Test Double

 

 

 

 

Demo: The Need for a Stub

 

 

 

 

 

 

 

 

Demo: Stub and Spy

 

 

 

 

 

 

 

 

Demo: Using a Mock

 

 

 

 

 

 

 

 

 

Now Let us use the Real Mocking framework to test DB related artefacts

 

Repository Mocking

 

 

 

 

 

 

 

 

 

 

 

 

View Mocking

 

 

 

 

 

 

 

Summary

 

 

 

 

Acceptance Test Driven Development

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Gherkin Tool for ATD

 

 

 

 

 

 

 

SpecFlow tool for ATD

 

SpecFlow is based on Gherkin and easy to use.

 

 

 

 

Introduction to Specflow

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Implementing Scenario Steps

 

 

 

 

 

 

 

 

 

 

Behavior Driven Development

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Summary

Reducing Class Coupling via below architecture for Good TDD

 

 

 

 

Blogger Labels: Test,Development,Part,Driven,unit,advantage,component,interface,Sometimes,components,repetition,developer,improvement,concepts,Introduction,Demo,Note,Here,scenario,Bark,parameters,Frameworks,Tests,Instead,Pass,Second,Third,Object,Method,Data,Integration,framework,Final,Project,Organization,NUnit,Artifacts,Creation,BaseClass,Design,Problem,Context,HttpContext,Dependency,Benefits,Code,Application,Double,Stub,Mock,Real,artefacts,Repository,View,Summary,Acceptance,Gherkin,Tool,Steps,Behavior,Class,architecture