I am a new comer to the art of unit testing and it has not yet become the part of my coding routine. However, even this early I have realized how useful writing unit tests can be. Specially writing unit tests gives you the understanding how the class will be used and where the errors can arise etc. For example passing the Type System.String to a method where the method expects a Type which implements a particular interface ICommand should result in an error because the System.String does not certainly implements the interface ICommand. But does the method validate the input?Now writing a test for this case is very simple. Just create the object, call the method with System.String as the Type parameter. [Test][ExpectedException(typeof(ArgumentException))]public void CanNotRegisterTypesNotImplementingICommand(){CommandLocater locater=new CommandLocater();locater.RegisterCommand(1,typeof(string));}Certainly I haven’t implemented the validation code for checking this, so the test is certainly failing. Until I feel like doing this validation, this test will always fail. Lot better than forgetting to write this code and getting an unrelated exception in any other section of the code is getting a failing test which will make sure that I’ll write the code necessary to implement this requirement.“Always write tests to break your code.”

Introduction of lambda expressions in .NET 3.5 have simplified many operations. One of them is sorting List<t> of complex types. For example assume that we have a type named Person and it has a Name property among other properties. Now if we want to sort a list of List<Person> on the Name property, we just have to use a single line of code.list.Sort((p1,p2)=>p1.Name.CompareTo(p2.Name));Or to sort on the Age propertylist.Sort((p1,p2)=>p1.Age.CompareTo(p2.Age));Here we are creating a delegate of Comparison<Person> using lambda expression and passing it to one of the overload of sort () method which accepts a Comparison<t>. The following code is breakdown of the above one liner into 2 lines.Comparison<Person> pc=(p1,p2)=>p1.Name.CompareTo(p2.Name);                                            list.Sort(pc);In short, we can use lambda expression to create delegates inline and pass them where ever a delegate can be passed. The List<t> class itself has many methods where you can pass delegates to perform certain actions. For example List<t>.ForEach() method.list.ForEach(o => Console.WriteLine(o.Name));Here we are outputting the names of persons in the list to the console without using a foreach loop.

We extensively use events in our .net programs. Most of the times, it doesn’t give you debugging worries. However in some cases, it can become an issue where your object containing event handler doesn’t get garbage collected due to event raising object holding a reference to the listener object. This happens when you listen to the events from a long lived object compared to the listening object.If you are coding in VB.NET then using the handles clause will guard you to an extent. Just remember to set the withevents variable to nothing after done. This will remove bindings between your event handlers and the object.However, if we are programming in C# or have to use AddHandler statements in VB.NET for attaching event handlers, remember to explicitly detach the handler from the event. As I said earlier, most of the times this does not become an issue at all. However, while creating highly event driven classes for your application, you don’t want objects sticking around more than they need to be. Also since the handler is still attached to the event, the handler will get invoked each time the event is fired. You can think the issues arising when this happens.Keep an eye on how you attach event handlers and make sure that you are detaching them in time.