Headaches in Test Driven Development
published on 6/2/2008 8:26:13 PM

I have been using Test Driven Development in few of my projects. All together I had a great experience using TDD. During this practice I ran into some blind corners and I would like to point that out and maybe get help from experienced TDD developers.

How to Test a Unit Test:

This is my biggest concern. How do you test a unit test? In a typical application we usually debug the application and step into the code. But it seems like you can only step into the unit test if you are using Microsoft Testing environment. My solution to this problem is to create a separate console application and call the method under test using the console application. This way I can debug the application and find the problem.

How Much to Test:

Basically, I am not talking about the code coverage but the dept of the unit test. Consider the following test that checks if the validation for the customer fired or not.

  [RowTest]

        [Row("","","",3)]

        [Row("john","","",2)]

        [Row("john","Senior Consultant","",1)]

        [Row("john","Senior Consultant","2122",0)]

        public void should_get_not_null_or_empty_broken_rules_for_customer_name_title_phone(

            string name, string title, string phone,int result)

        {

            Customer customer = new Customer() { Name = name, Title = title, Phone = phone };

            validationEngine.Validate<Customer>(customer);

 

            Assert.AreEqual(result, validationEngine.BrokenRules.Count());

        }  
 

 Although I am checking the validation against different inputs but I am not checking that if I am getting the right message i.e. name should not be null or empty, title should not be null or empty etc. Should I be concerned about this or should I feel satisfied by counting the number of broken rules?
 

Setting Up the Object under Test:

Objects have dependencies with other objects. So, sometimes when you need to test a certain object you need to set up the environment for that object. That may require creating other objects and so on. A good technique is to use the object builder pattern. Here is an example:
 

public class UserBuilder
{
private MembershipUser user;
private tblUserInfo info;

public UserBuilder New(string userName, string password, string email)
{
user = Membership.CreateUser(userName, password, email);
info = new tblUserInfo() { DateCreated = DateTime.Now, DateModified = DateTime.Now, Active = true };
return this;
}

public UserBuilder WithFirstName(string firstName)
{
info.FirstName = firstName;
return this;
}

public UserBuilder WithLastName(string lastName)
{
info.LastName = lastName;
return this;
}

public UserBuilder WithInfo(UserInfoBuilder infoBuilder)
{
infoBuilder.New((Guid)user.ProviderUserKey, user.UserName);

return this;
}

public UserBuilder AssignRole(string roleName)
{
Roles.AddUserToRole(user.UserName, roleName);
return this;
}




public MembershipUser Build()
{
return user;
}


}

Usage:

[Test]
[RollBack]
public void should_be_able_to_assign_tutor_role_to_the_user()
{
var alice = new UserBuilder().New("alice", "alice1234$", "alice@yahoo.com")
.AssignRole("Tutor").Build();

var vAlice = Membership.GetUser(alice.UserName);

Assert.IsTrue(Roles.IsUserInRole(vAlice.UserName, "Tutor"));

}

How do you setup the object envirnment?

These are just some of the headaches in Test Driven Development. This post is in no way to degrade Test Driven Development but to improve it by overcoming the hurdles.