Getting Started with Test Driven Development Concept and Guidelines

Recently I have been encouraged to start working using Test driven development , so I took like a quick run over the Concepts and Guidelines and
Decided to post my achievement Notes and result of each phase I study ,implement and give some points to those who are interested in getting started
just like me so lets start

First

The Main concept or shall I say the main though that should be in your mind while Doing TDD is simply this “Every new feature begins with a test” what does this mean ?

It means simply you don’t write any code you begin with you tests, maybe your test cases not just one many as many as you think of start throwing those
tests before even writing interfaces to test them that’s it the first and most important yet the basic foundation of Test Driven Development is to
“Write tests first ” simple enough.

Second

These Tests will fail “Cause there is not code to test so they should fail else then there is something wrong with your tests” Mostly these tests are
driven from use cases, test cases or user stories

Note : What is the defference why should I write tests first “heck that takes even more time to do the whole thing ”

Answer : why ? because you write your tests before your code is written so you re-factor and accommodate your code to use unit tests while you first
write it, Also it helps you focus on the Business side of your application makes you focus on the Requirements at most and everything else comes second


Here is an excellent example of code that is really simple and illustrates TDD with code if you are tired of me running my mouth http://www.codeproject.com/KB/dotnet/tdd_in_dotnet.aspx


Unit Testing Framework there are so many frameworks in Unit testing, for me I prefer NUnit and for Mocking I use MOQ framework

Test Driven Development Cycle

Ok after I did some reading hashing and slashing I was able to define the TDD “Test Driven Development” Cycle and it came like this

1. Write a test or more

2. Run the test. It fails to compile because the code you're trying to test doesn't even exist yet! (This is the same thing as failing.) so if it
throw exception cause there is not method or a class called blab la bla then that counts as a failed test

3. Write a bare-bones stub to make the test compile in other words make the test class build by creating the necessary classes and methods

4. Run the test. It should fail since you did not logic so far so it would make since that the logic you are trying to test is not working and it
should fail. (If it doesn't, then the test wasn't very good.)

5. Implement the code to make the test pass, In this step you work on passing the test in other words write the necessary code to make this test
pass

6. Run the test. It should pass “now that your logic is done and you are probably using the logic write”. (If it doesn't, back up one step and
try again.)

7. Last Start over with a new test! And go all over one time

Coding By intention

A very useful concept use for TDD is called Coding by intention it is simply the process of writing code while thinking “i am going to need”
and not I need to . another explanation is to write the test without consideration of what should and what should not be implanted wither it is a class
or a method, and thinking I’m going to need helps you do that

The Result was

well tested code easy to read and debug and yes it is very reusable in so many ways

Another yet very important primary concept of the TDD

"Dont write any code untill you have a test that fails"

The most important steps of the Test driven development cycle is

Write as simple and small code to make the application only compile next step write enough code to make the test pass