Test your self before test your code

A few days back I had written a post on Test Driven Development. And many of my friends raised questions: why should I test, and is there anything built-in in Visual Studio? They also wanted more explanation on Test Driven Design. So here again I will go a bit deeper into testing. OK, it's just a little bit deeper.

First thing, as per the title, you should test yourself before you test your code. It is not philosophical, but it is pure technical. If I am writing a test for my code, I should know why I am writing it. How am I going to write it? These few questions must be answered before writing the test. Now, we are normal kind of coders. I can't say that whatever code I am writing is going to execute perfectly. In fact, in most cases the reverse is true. Every damn time I forget something to consider and that crashes my code. If you are like my friend Aalap, then you can go on and on without writing tests. He is damn good with Windows technology and writes code like anything. And a bit lucky because whenever he writes code, that piece of shit executes perfectly. But I am not a genius like him, so I need to test it.

Again we go with my mathematical functions. Because I just love mathematics. And this time we are using Visual Studio testing facility. You can go with NUnit; it's almost the same, just a few syntax changes here and there. But it is not a big deal. Start with a new console application. Add a new class MathUtil to it. And make it a static class for simplicity. Now, I am not putting a screenshot for "how to use Visual Studio???". If you don't know, this article is not for you; you better go and study some basics before jumping to this. Sorry…

Again we have a static function to add something. Let's start with integer. So, here is an add method for adding integers.

public static class MathUtil { 
public static dynamic AddData( int a, int b) { 
  return a + b; 
} 

}

Damn sweet. A simple method to add two integers. Now, time for testing. Add another project to the solution; that project will be the test project. You will find the test project if you are running Visual Studio Pro or greater. After adding the project, we just have to remember Paul Allen and click the right mouse button on the Add Data method. Then just click create unit test and mighty Visual Studio creates the test for us. Here, we get code like this:

  ///A test for AddData /// 

[TestMethod()] public void AddDataTest() { int a = 0; // TODO: Initialize to an appropriate value int b = 0; // TODO: Initialize to an appropriate value object expected = null ; // TODO: Initialize to an appropriate value object actual; actual = MathUtil.AddData(a, b); Assert.AreEqual(expected, actual); Assert.Inconclusive( "Verify the correctness of this test method." ); }

Now, we need to modify it to run the test. And the code will look something like this:

[TestMethod()] public void AddDataTest() { int a = 10; // TODO: Initialize to an appropriate value int b = 10; // TODO: Initialize to an appropriate value object expected = 20; // TODO: Initialize to an appropriate value object actual; actual = MathUtil.AddData(a, b); Assert.AreEqual(expected, actual); }

This test works perfectly. Yeah, we have written a correct function. Now, the client comes and tells us that he needs the same for float. Why not??? We have overriding in software engineering. We will use it. And ta da… We have another function like this:

public static dynamic AddData( float a, float b) { 
  return a + b; 

}

This will work for float. We will do the same thing for testing now. Right-click and create a unit test. We have our method here like this:

[TestMethod()] 
public void AddDataTest1() { 
float a = 0F; // TODO: Initialize to an appropriate value 
float b = 0F; // TODO: Initialize to an appropriate value 
object expected = null ; // TODO: Initialize to an appropriate value 
object actual; 
actual = MathUtil.AddData(a, b); 
Assert.AreEqual(expected, actual); 
Assert.Inconclusive( "Verify the correctness of this test method." ); 

}

If you have noticed, this is not overriding in the test. It just adds "1" after the test name. Who cares, the test project is not going to the client side. Yeah, true. But I may not be the only one working on the project. There are many who are working and using my methods, testing them. This name will confuse them. So what should I do? Add a definition to the name itself. Then the method looks like:

[TestMethod()] 
public void AddDataTest_Float() { 
float a = 10F; // TODO: Initialize to an appropriate value 
float b = 10F; // TODO: Initialize to an appropriate value 
object expected = 20; // TODO: Initialize to an appropriate value 
object actual; 
actual = MathUtil.AddData(a, b); 
Assert.AreEqual(expected, actual); 

}

OK, this test is for float data. We will change the previous method for integer data. And once again the client comes asking for double. How can I say no??? He is my client. No problem, sir, we'll go for double too. Here is the method I wrote. I made it somewhat generic so I don't have to write it again and again.

public static dynamic AddData( object [] data) { 
dynamic result = data[0]; 
for ( int i = 1; i < data.Length; i++) { 
  result += data[i]; 
} 
return result; 

}

Now this will add almost anything. And also any amount of data. Now, create a test for it. The test method looks somewhat like this:

[TestMethod()] 
public void AddDataTest_ObjectArray() { 
object [] data = new object [] { 10, 10, 10 }; // TODO: Initialize to an appropriate value 
object expected = 30; // TODO: Initialize to an appropriate value 
object actual; 
actual = MathUtil.AddData(data); 
Assert.AreEqual(expected, actual); 

}

Here, I just want to say that you just don't start testing because someone says so. Or just because you love me so much that you can't ignore my request to make the application the way it should be made. Just know where you need testing, and for testing you should know what you want to test. There are many methods available to check null, inequality, and exceptions. Use the appropriate method for that. There are many books available just to explain how to test.

A book I recently came across is The Art of Unit Testing. It's a wonderful book explaining every minor detail of testing. Just don't waste your time and energy on clicking buttons in your own application. That is a job for the testing department. But unit testing is our responsibility; it is the job of the coder to test his functionality before adding it to the system. Do the unit test and become confident about your work. There is no need to add unnecessary bugs to the bug tracker.

Please let me know if any further explanation is needed.