14 Mar 2007

How To: Unit Test Hidden Classes

No Comments Uncategorized

Unit testing is an important part of developing high quality software. Many of you are probably not familiar with the term Unit Testing. Wikipedia defines Unit Testing as

In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, web page, menu etc, while in object-oriented programming, the smallest unit is always a Class; which may be a base/super class, abstract class or derived/child class. Units are distinguished from modules in that modules are typically made up of units.

One of the most popular ways to Unit Test .NET code is NUnit. However, I am not going to get in to the basics of Unit Testing in this post. If you are interesting in learning more about NUnit and Unit Testing please visit NUnit QuickStart page. This post is going to deal with how does a developer test a class that has a private or hidden constructor.

Private constructors are very useful tool in a developer arsenal, because there are many instances when you want to give the consumer of your code access to the object but not the ability to create it. I have provided an example below:

public class Customer
{
	public static Customer GetCustomer(int customerId)
	{
		// get information from database
		Customer customer = new Customer(customerId, database.GetString("CustomerName"), database.GetDecimal("CustomerAccountBalance"));

		return customer;
	}

	internal Customer (int id, string name, decimal accountBalance)
	{
		// set customer properties
	}

	public int Id { get { return _id; } }

	public string name { get { return _name; } }

	public decimal AccountBalance { get { return _balance; } }

	public void DebitBalance (decimal amount) { ; }

	public void CreditBalance (decimal amount) { ; }
}

There is no real way to test the constructor of this Customer object unless you embed your Unit Tests right in your code. But personally I find that method sloppy because you are mixing QA and Development together, and they should be seperate to at least maintain good software development practices.

If you were to create a Unit Test in the same assembly as the Customer class above, it would look something like this:

Customer customer = new Customer(/* ID */ 20, /* Name */ "Joe Customer", /* Account Balance */ 3400.0M);

// credit the customer $30.00
customer.CreditAccount(30M);

// assert that the original account balance plus the additional credit are equal
Assert.AreEqual(3430.0M, customer.AccountBalance);

But this isn’t very useful if you want to separate your code from your tests. So what is needed is a way to instantiate a private method from outside an assembly. So in order to solve this problem I created the following code that I use in all my Unit Test Projects for just this circumstance. (note: The following code is not for the faint of heart. It combines generics and use of the reflector namespace).

using System;
using System.Collections.Generic;
using System.Reflection;
using System.Security.Permissions;

public static class TestHelper
{
	public static T CreateInstanceForNonPublicConstructor<T>(params object[] parameters)
	{
		List<Type> constructorSignature = new List<Type>(parameters.Length);

		// add all the types in order of the parameters to create the consturctor
		// signature so that the correct constructor can be retreived
		foreach (object parameter in parameters)
			constructorSignature.Add(parameter.GetType());

		ConstructorInfo typeConstructor = typeof(T).GetConstructor(BindingFlags.Instance | BindingFlags.NonPublic, null, constructorSignature.ToArray(), null);
		return (T)typeConstructor.Invoke(parameters);
	}
}

In order to use this code to instantiate the Customer class above, in an external assembly, the same Unit Test from outside the assembly would look like this:

Customer customer = TestHelper.CreateInstanceForNonPublicConstructor<Customer>(new object[] { /* ID */ 20, /* Name */ “Joe Customer”, /* Account Balance */ 3400.0M });

// credit the customer $30.00
customer.CreditAccount(30M);

// assert that the original account balance plus the additional credit are equal
Assert.AreEqual(3430.0M, customer.AccountBalance);

So I have demonstrated that it is possible to fully test all objects from an external assembly using standard Unit Testing as well as keeping your code separate from your tests and upholding good software development practices.

Update: It wasn’t very clear that this code can apply to any type of constructor (public, private, and internal), this code I have in TestHelper can be used in any development process you need it in, I have just chosen to apply it to Unit Testing.

14 Mar 2007

Remote Desktop for Linux

No Comments Uncategorized

One of features in Windows that I could not live with out is the Remote Desktop Protocol (RDP). It is one of the best tools out there for remote viewing of your desktop. I use it at work to keep track of my Windows servers as well as log in to my desktop at home to do programming or check personal e-mail. Remote Desktop is fast, flexible, and doesn’t have the problem of having to do a full screen refresh to see what has changed on your desktop. So in a sense it is smart because it only updates the part of the screen that have refreshed. You don’t even loose screen refresh performance when you login to a machine through RDP and then launch another instance of RDP to remote in to another machine from your already remote machine, I find that very impressive.

I have always been using VNC to monitor my Linux servers from my Windows desktop, I have also always wished there was a way login to my Linux servers the way I login to my Windows servers. Today I found the answer and it is 2X Terminal Server. You can read more about this at the digg link below.

read more | digg story

12 Mar 2007

5 Easy Steps To Get iTunes Working On Windows Vista x64

41 Comments Uncategorized

This morning I wrote about the problems I had installing the newly released iTunes for Windows Vista Ultimate x64. I just recently found a solution to the problem error that iTunes was giving me when I tried to install it this morning. The error was:

iTunes could not be installed because Visual Basic Script (VBScript) is not installed or has been disabled. Make sure VBScript is installed, turn off script blocking in anti-virus and personal firewall software, re-register VBScript, and then install iTunes.

And the solution is to simple register the vbscript.dll. To do this you just need to follow the next 3 steps:

  1. Open up the Command Prompt as an Administrator (Go to All Programs > Accessories and Right Click on Command Prompt and then choose Run as administrator)
  2. Type cd C:\Windows\SysWOW64
  3. Type regsvr32 vbscript.dll (This registers VB Script with your computer.)
  4. Now install iTunes as you normally would by double clicking on the install program and wait for iTunes to finish installing.
  5. Type regsvr32 /u vbscript.dll (This unregisters VB Script with your computer.)

If the above didn’t work for you, you may be using a 32-bit version of Windows. Please check out the Apple Support #304405, which will walk you through the process to enabled VBScript on Windows 32-bit.

Please read more if you would like to hear my rant against Apple and the security vulnerability this opens up in the Windows Operating System. On a side note Apple should be congratulated, I guess, for fixing a bug I documented almost 3 months ago when trying to install iTunes on Vista x64.
Read more