So this is how this idea began...
I figured that, in the interest of bettering those who surround me and those who follow this blog, I would begin at the very start. Just like we all learned c#, let’s learn c# from scratch as if it’s brand new but using Test Driven Development.
So this is my first in potentially a series… “Beginning C# through Test Driven Development”.
So what is an Object?
Objects are a collection of information and functionality. In other words, they are state and behavior, respectively. Every object has some type of data that we wish to manipulate and get some other type of data back out of it. Every object is a black box to which we put something in it, tell it to do something, and then usually get something back out.
Let's start with the basics of why we use objects.
What is inheritance?
Inheritance is taking an Object that someone has already defined and adding more functionality to it. The idea is that you already have something doing most of what you want to do, but you just need to add a little bit more to it. You take what already exists and inherit it, then apply new things to it so you do not have to copy and paste that functionality.
What are Combination, Aggregation, and Containment?
When you have an object that uses or ‘contains’ other objects inside of it, this is thought of as Aggregation or Containment.
Inheritance is often known as the “IS A” relationship. A dog is a mammal. A mammal is an animal.
Combination is often known as the “HAS A” relationship. A dog has a leg. A leg has a foot. A foot has a toe.
Lesson 1: Hello world in TDD
First, we will need to create a C# Class Library project.
In .net a dll or exe is called an Assembly. A class library project creates a dll assembly. We are choosing to use a dll assembly because our unit test framework will require a dll and cannot execute tests from an exe file.
Now that you have a dll, we will have to add references to a unit testing library. I have chosen MbUnit as the unit testing framework/library.
You will need to go download MbUnit and install it. Or you can download Nunit and install that.
Ok now that you have a unit test framework, go back to visual studio and expand your class library project in the solution explorer.
Right click on “References” and choose “Add reference…”
Choose the MbUnit.Framework (Or NUnit.Framework) and hit ‘Ok”.
You have just added MbUnit.Framework.dll as an assembly reference. This allows your dll to use functionality from that dll.
Now you have code that looks like this:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace HelloWorld
{
public class Class1
{
}
}
Frankly, the class name is not appropriate and we do not need those using statements (that visual studio automatically adds for you).
We will first rename the class by right clicking “Class1.cs”in the solution explorer and choosing rename:
I renamed it to “HelloWorld.cs” and allowed visual studio to change the name of the class as well. Then I removed the using statements. My code looks like this:
namespace HelloWorld
{
public class HelloWorld
{
}
}
Now we are going to add what is called an attribute to our class. An attribute basically just adds description to your class. For now just follow along but you can research more on attributes separately if you desire.
Your code should now appear like this: (or use NUnit.Framework)
using MbUnit.Framework;
namespace HelloWorld
{
[TestFixture]
public class HelloWorld
{
}
}
A test fixture is a class that represents a set of tests around a particular area of functionality. I believe the term fixture comes from electrical engineering where they would place circuits and a test on a fixture.
So let’s put our test in this fixture. We’ll add a method and give it a “Test” attribute. Methods are behavior or functionality. They can be called from other places in the program to execute a task or some behavior. Ours will start out with nothing in it.
Here’s how it should look:
using MbUnit.Framework;
namespace HelloWorld
{
[TestFixture]
public class HelloWorld
{
[Test]
public void HelloWorldTest()
{
}
}
}
Go ahead and Build the project by going to the build menu:(or shift + F6) (or F6 to build the whole solution, which happens to be our 1project right now)
So now we can run the MbUnit application to fire off this test.
By default this is C:\Program Files\MbUnit\bin\MbUnit.GUI.exe
Choose assemblies -> add assembly
Browse to your dll…on vista it should be in C:\Users\<userid>\Documents\VisualStudio 2008\Projects\HelloWorld\HelloWorld\bin\Debug
If you click run, it will pass:
So we have a basic framed out test and test fixture but wearen’t doing anything yet!
What is TDD?
TDD stands for test driven development. (in some circles it’s test driven design, but in our case we’re talking about the development).
Generally the mantra for TDD is “Red, Green,Refactor”
1. make just enough test to fail (RED)
2. write just enough code to pass (GREEN)
3. REFACTOR to remove any duplication (DRY or do not repeat yourself)
Let’s go ahead and make just enough test to fail using astring object.
using MbUnit.Framework;
namespace HelloWorld
{
[TestFixture]
public class HelloWorld
{
[Test]
public void HelloWorldTest()
{
string helloWorld = null;
Assert.AreEqual("Hello World!", helloWorld);
}
}
}
NOTE: There are 3 basic parts to any test.
- Set up some state. Here we've defined a string.
- Do some behavior. Right now we don't really have any behavior, but normally there would be a method called .
- Assert the state is what you expect
Build this then run the test again. See what happens.
We failed the test. This is GOOD.
Now let’s make the test pass by changing the null to “Hello World!”
using MbUnit.Framework;
namespace HelloWorld
{
[TestFixture]
public class HelloWorld
{
[Test]
public void HelloWorldTest()
{
string helloWorld = "Hello World!";
Assert.AreEqual("Hello World!", helloWorld);
}
}
}
When we build and run the test it now passes.
Red, Green…
Now we should refactor out any duplication.
Do we have any?
Well we have this “Hello World!” string in there twice. Would it be much of a test if we removed that?
I’d say for testing practices sake, we should probably leave each string defined separately! More reasoning for that will be apparent as you learn more about TDD, but for now let’s recap what we’ve learned in this post.
We’ve introduced the class and string keywords. We saw how to create a dll, add references to it, and how to write a basic unit test using MbUnit. Lastly, we saw how to do the basics of TDD by making it red, making it green, and then checking for duplication.