Human-Debugger.net - Blogging about Cultivating a Culture, Agile Training, Continuous Delivery, Performance Optimization and Get Things Done

TDD: from beginner to pro (#2)

Hi, so this is my first step in the TDD world, First read “TDD: from beginner to pro” introduction.


I Had to write a decision tree algorithm which has a special format (SVMLight format). The algorithm should run on this data and create the tree. I will focus on the SVMLightVector class.


I should also add that my examples for this session would be taken from the world of text mining.
our samples would be documents and we should classify each document to its subject.
for example if we hold a document D1 (bunch of words separated by spaces), the decision tree would help us to decide whether this document (D1) is a sport article or finance.


the SVMLightVector class holds:



  • Features – for example if we hold a document each word is a feature.
  • Classification – the subject of the features.

so I wrote this code, or if I’ll be TDD-ly Correct: attend to write this code:


public class SVMLightVector
{
private IList<string> m_classifications;
public IList<string> Classifications
{
get { return m_classifications; }
set { m_classifications = value; }
}

private IDictionary<string, long> m_features;
public IDictionary<string, long> Features
{
get { return m_features; }
set { m_features = value; }
}

public SVMLightVector()
{
// do nothing.
}

public SVMLightVector(string svmLightFormat)
{
Classifications = new List<string>();
Features = new Dictionary<string, long>();
}
}


So I thought to myself… Testing properties? isn’t it wasteful? so I decided to stop wasting my time and start coding.
So why do I think it is good to right such tests:



  • because that this is what I read in all TDD books, test everything, do not have even one line not tested…
  • why not?! it is simpleasy (simple&easy)….
  • also, I must admit that I found it useful to write those tests for properties, how many times it happens that you copy&paste&change one property to another one, instead of using the snippet, this trick can cause strange bugs, believe me.

so here are my tests:


[TestMethod()]
public void FeaturesProperty_SetProperty_GetTheSame()
{
IList<string> classifications = new List<string>();
classifications.Add(“class1″);

IList<string> expectedClassifications = new List<string>();
expectedClassifications.Add(“class1″);

SVMLightVector vector = new SVMLightVector();
vector.Classifications = classifications;

//Assert.AreEqual<IList<string>>(expectedClassifications, vector.Classifications);
CollectionAssert.AreEqual((IList)expectedClassifications, (IList)vector.Classifications);
}

[TestMethod()]
public void FeaturesProperty_SetPropertyToWrongClass_GetDifferentClass()
{
IList<string> classifications = new List<string>();
classifications.Add(“class1″);

IList<string> expectedClassifications = new List<string>();
expectedClassifications.Add(“class2″);

SVMLightVector vector = new SVMLightVector();
vector.Classifications = classifications;

//Assert.AreNotEqual<IList<string>>(expectedClassifications, vector.Classifications);
CollectionAssert.AreNotEqual((IList)expectedClassifications, (IList)vector.Classifications);
}


Simple isn’t it?
You can see my first Test-Bug. I tried to use the Assert.AreEqual<> which is not what I needed, because this one compares objects.
but I easily found this: CollectionAssert.


One Question to myself:



  • Why it(CollectionAssert) doen’t use generics?!


Good night for now.




I should thanks to two people that don’t even know that I’ve learned from them a lot.
1) Roy Osherove – I’ve been reading his blog and using his standards of naming test methods and some more standards.
2) Oren Ellenbogen – Which I read his code and start learning this stuff from their.