Share Learning Area

Inversion of Control

Desirea Herrera — Sun, 26 Jul 2009 17:04:32 GMT

While I was reading The Art of Unit Testing by Roy Osherove, I found references to topics that required more investigation. Inversion of Control or IoC was one of them. I vaguely remember reading about it somewhere but being a tech trainer of way too many technologies, and now a lab developer (basically quality assurance checking & screnshotting of MOC labs & labs from other companies), I've let some topics slide away in favor of stuff related to my job. It's part of the reason I started writing this blog, to hone my skillsets. And now, on to Inversion of Control:

Inversion of Control is based on the idea of flow control. When you start programming, you learn to write code in classes and methods that control the flow of the program. Your code calls methods that do something and answer back to your code. In Inversion of Control, your central classes wait for the phone call that tells them things they need to know to perform their own activities.

The example onWikipedia shows a serverFacade class that initially takes an object parameter to its respondToRequest method. The object is a request for data. The respondToRequest method then uses a DAO (Data Access Object) to get data via it's getData method and convert the data via the aspect's convertData method after using the businesslayer object to test if that object is valid. Based on the first implementation, the serverFacade object is coupled to the DAO object. In the lab of OOP, coupling is discourage. Since the serverFacade shouldn't know anything about how to convert data, or what to return if the data conversion fails (it is only a facade after all), the second implementation moves all the data conversion and return decisions to the DAO class. This in effect, decouples the two classes.

In Martin Fowler's article Inversion of Control Containers and the Dependency Injection pattern, he uses a simple class that splits out finding all movies to a finder class. Problems arise when his friends want that functionality for their programs. They might want to store movies in a different format or in a database. An interface or abstract class solves this by allowing the new developer to create a new class to pass to the MovieLister class that can find all of the movies in their own way via their own implementation.

The key points to both of these examples is that :

The classes need to have very specific goals. If an activity doesn't correspond to the method or class, it needs to be moved out.
In order to allow for different external dependencies like how the movies are stored and retrieved, create an interface or abstract class. (This idea makes your program easier to fit different situations as needed.)

Based on Fowler's explanation, what we're really talking about is setting up "plugins" for our software. Essentially you now have the ability to plugin any external movie storage into his MovieLister class. Data storage is only one of the types of external or outside dependencies your software could come across. It could also rely on network availability, configurations as well as configuration files or data stored on a network, or outside services.

Fowler asserts that Inversion of Control is a common characteristic of a framework. In Inversion of Control he says:

"A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points."

Fowler also thinks Inversion of Control Containers is too generic and renames this to Dependency Injection and further discusses the Server Locator pattern. I highly suggest you read his full article.

Going back to the Wikipedia article, it mentiosn that Inversion of Control is also known as the Hollywood Principle. Basically is the ""Don't call us, we'll call you." concept. IoC takes the integration and configuration of the system out of the application, and performs dependency injection.

Unit Testing Review List

Desirea Herrera — Tue, 07 Jul 2009 17:26:18 GMT

User Defined Casts

Desirea Herrera — Sun, 05 Jul 2009 18:17:21 GMT

There are times when you may find yourself writing code to move data from a type you defined to another type either predefined or user defined. Of course we are all aware of polymorphism between derived types. This isn't always possible or practical depending on your intentions. It is particularly hard when you're converting between a primiritive type and a user defined type. The answer to this dilemma is to define your own cast.

Review
As you know, casting is the process of converting one datatype to another. Implicit conversions are automatic and can occur when no data will be lost. Data can be lost when the amount of memory space reserved for the target datatype is less than the memory space used used by the source datatype. Just like trying to pour 2 cups of water into a 1 cup container, data can be lost like the water that spills over. The answer to this dilemma is the explicit conversion where you explicitly acknowledge that the data will be lost and allow it to be lost. These types of casts are available for predefined datatypes. Normally the predefined casts and polymorphism will suffice, but for those times when you find yourself moving data manually between types, user defined casts are the answer.

Syntax
Type conversions for your own datatypes are possible but you must define them yourself. You do this by defining your cast within one of the classes from which you will cast. You will also need to mark your cast operation as either implicit or explicitr. A good rule of thumb is to define your cast as explicit if therre is any risk of an exception or if any of the data in the source type might fail to be transferred to the target type. Casting operators can be written into structs and classes. The syntax is similar to overloading an operator as shown below:

// The person class is an abstract class defining basic person information.
public abstract class Person
{
public string firstName;
public string lastName;
public Person(string first, string last)
{
this.firstName = first;
this.lastName = last;
}
public Person()
{}
}

// The Farrier class inherits from the Person class.
public class Farrier : Person
{
public string expertise;
public Farrier(string first, string last, string expertise):base(first,last)
{
this.expertise = expertise;
}

// Note the explicit conversion operator.
// This does not technically need to be explicit as no data will be lost and no exceptions will occur.
public static explicit operator Veterinarian(Farrier value)
{
string fName = value.firstName;
string lName = value.lastName;
string specialty = value.expertise;
return new Veterinarian(fName, lName, specialty);
}
}

// This is the Veterinarian class that in herits from the Person class.
public class Veterinarian : Person
{
public string specialty;
public Veterinarian(string first, string last, string specialty):base(first,last)
{
this.specialty = specialty;
}

// Note the implicity conversion operator.
public static implicit operator Farrier(Veterinarian value)
{
string fName = value.firstName;
string lName = value.lastName;
string expertise = value.specialty;
return new Farrier(fName, lName, expertise);
}
}

// The Form code.
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}

// Using the implicit conversion
private void farrierToVet_Click(object sender, EventArgs e)
{
Farrier a = new Farrier(farrierFName.Text, farrierLName.Text, farrierExpertise.Text);
Veterinarian b = (Veterinarian)a;
veterinarianFName.Text = b.firstName;
veterinarianLName.Text = b.lastName;
veterinarianSpecialty.Text = b.specialty;
}

// Using the explicit conversion.
private void vetTofarrier_Click(object sender, EventArgs e)
{
Veterinarian b = new Veterinarian(veterinarianFName.Text, veterinarianLName.Text, veterinarianSpecialty.Text);
Farrier a = b;
farrierFName.Text = a.firstName;
farrierLName.Text = a.lastName;
farrierExpertise.Text = a.expertise;
}

// Attempting to use polymorphism.
private void polymorphicFarriertoVet_Click(object sender, EventArgs e)
{
Farrier a = new Farrier(farrierFName.Text, farrierLName.Text, farrierExpertise.Text);
Person c = a;
// The following causes compile error:
//Cannot implicitly convert type 'UserDefinedCasts.Person' to 'UserDefinedCasts.Veterinarian'.
//An explicit conversion exists (are you missing a cast?) C:\Documents and Settings\Desirea\My Documents\Visual Studio 2008\Projects\UserDefinedCasts\UserDefinedCasts\Form1.cs 43 30 UserDefinedCasts
//
// Veterinarian b = c;
MessageBox.Show("Conversions would not work even with explicit conversion. Person does not contain a casting operator.",
"Polymorphic Conversion Not Possible",
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
}

Usage
User defined casts are a good way to reduce code. If you find yourself writing code to move data from one of your datatypes to another, defining your own casts within one of the classes or structs will make the job a lot simpler. It's also a good solution when inheritance won't resolve the issue via polymorphism. You can also decouple classes that while containing similar data do not necessarily need to be tied together as in the case of integers and floats. I'm sure someone has some more suggestions as to how to use user defined casts. Feel free to post them below.

C# Preprocessor Directives

Desirea Herrera — Wed, 15 Apr 2009 03:48:51 GMT

Here’s just a few notes on preprocessor directives.

They’re never terminated by a semi-colon.

They can never be translated to any commands in code

They affect the compilation process

They can prevent compilation of positions of source code. This is great for having 2 release versions of your application. It’s also great for eliminating debug information source code.

# define identifier

This directive tells the compiler that the identifier or symbol exists. It does not define a valid you for that identifier. These symbols work as a true or false designator.

# undef identifier

This directive tells the compiler that the identifier or symbol should cease the existing. Any test for the identifier will result in a false reading.

In either case nothing will happen if the symbol does or does not exist.

#if Identifier

//some code

#endif

This directive combination tells the compiler to conditionally execute the code block between the directives based on the return of the identifier. If the identifier has been defined using the #define directive, the code will execute. If it has not been defined or has been undefined using the #undef directive the code will not execute.

#elif

This directive acts the same way as and else if statement. It fits in with the #if and the #endif directives.

#if Identifier

//some code

#elif otherIdentifier

//some code

#endif

C# Allows you to use comparison operators like && and = =.

#warning #error

These directives cause warning or error messages when the compiler encounters them. The error directive will display any text to the user as if it were a compile error and then stops compilation whereas the warning directive will continue compiling the application.

#region

#endregion

These directives work in conjunction with each other to organize the layout of your code. They don’t affect compilation.

#line

This directive will alter the file name and line number information to output by compiler warnings and error messages. This is most useful when coding in conjunction with some other assembly that might alter the code you type in before sending the line number to the compiler and the line numbers may not match up correctly.

#pragma

This directive will suppress or restore compiler warnings. It can be implemented on class or method levels.

Programming Articles Archive

Desirea Herrera — Wed, 07 Jan 2009 05:48:30 GMT

I found this question over at stackoverflow.com about what are the best articles on programming. I've compiled the list of suggestions here for easy reference. I'm guessing it will take some time to get through all of these articles myself.

Teach Yourself Programming in Ten Years
Painless Functional Specifications, by Joel Spolsky.
Why Bother?
What's a Spec?
But... How?
Tips
The Programmer Competency Matrix is an excellent reference to gauge your development skills.
The Free Lunch Is Over: A Fundamental Turn Toward Concurrency in Software
No Silver Bullet - Essence and Accidents of Software Engineering.
How I Explained REST to My Wife
Coding Without Comments,
http://steve.yegge.googlepages.com/being-the-averagest
Big Ball of Mud
"How to Write a Spelling Corrector"
Hackers and Painters
Why functionnal programming matters
bunch of very good ones here
The Law of Leaky Abstractions
Great Hackers by Paul Graham
10 Principles Of Effective Web Design
Making Wrong Code Look Wrong by Joel Spolsky on Hungarian Notation.
Code Tells You How, Comments Tell You Why by Jeff Atwood.
What Every Programmer Should Know About Memory [pdf] by Ulrich Drepper
What Every Computer Scientist Should Know About Floating-Point Arithmetic by Goldberg.
What to do when you're screwed by Rands
"What is Software Design" by Jack W. Reeves
The Cathedral and the Bazaar
Eric Sink's My life as a code economist.
Chris Brumme's excellent essay on finalization in .NET.
gory inner details of the exception model in .NET.
Ian Griffiths on doing work without threads.
Ian Griffiths again on deadlock complexities.
Raymond Chen on software development taxes.
Jan Mikovsky on the fractal nature of UI design problems.
A programmer's view of the Universe, part 1: The fish by Steve Yegge
life in the kingdom of nouns
Why numbering should start at zero by E.W. Dijkstra
Secrets of the Little Blue Box by Ron Rosenbaum
The Pinocchio Problem by Steve Yegge
Go To Statement Considered Harmful by Edsger W. Dijkstra
Characterizing people as non-linear, first-order components in software development by Alistair Cockburn
This is very specific to Java development, but an excellent overview of memory management issues by Attila Szegedi. Makes me want to buy him a beer :)
A day in the life of a memory leak hunter
Yet another day in the life of a memory leak hunter
Memory leak hunting still doesn't end, or: Serialization also requires a bit of manually imposed amnesia
Anything in Hanselminutes, or Scott's Blog.
Picture Hanging by Colin MacDonald.
They Write The Right Stuff, a timeless article by Charles Fishman published in FastCompany 1996.
How to be a Programmer: A Short, Comprehensive, and Personal Summary by Robert L. Read
Cert Secure Coding Standards is a gem
Coding: It's Just Writing by Jeff Attwood.
Exploding Offer Season by Joel Spolsky
10 Useful Techniques To Improve Your User Interface Designs by Dmitry Fadeyev.
Practice To Perfect: The Quality First Model by Bertrand Meyer.
Effective Unit Testing by Tim Burns.
Object Mentor Articles

If any of them get out of date, just mention it here with a comment and the updated link.

What's a Service Contract in WCF?

Desirea Herrera — Wed, 03 Dec 2008 16:04:43 GMT

It's important to first understand what defines a service contract. Basically a service contract defines the group of operations in a service, the operation's signatures and message datatypes. It also defines the location of the operations and the specific protocols and serialization formats that support communication with the service.

In WCF, we define a service contracts with method and class attributes. The following is a simple service with it's associated attributes:

// Step 1 Import the necessary namespace
using System;
using System.ServiceModel;

namespace myHoakyService
{

   //Step 2 Use the ServiceContract attribute to 
   //identify a class or interface that defines a 
   //WCF service contract for clients.
  [ServiceContract(Namespace=http://localhost/HoakyService)]
   public interface IHoakyService
  {

       //Step 3 Identify Service Operations 
       //with the OperationContract 
       //attribute and expose it to clients
       [OperationContract]
       string HoakyMethod();

       //Note: You can even include methods 
       //that are not exposed to clients.
       string HoakyNonAccessibleMethod();
  }

  //Note: You can even apply the ServiceContract to classes
  [ServiceContract(Namespace=http://locahost/HoakyClassService)]
  public class HoakyClassService
  {

     [OperationContract]
     string HoakyClassMethod()
     {
       return "This is a hoaky method.";
     }
  }

//Step 4 Design a class that implements the ServiceContract Interface
  public class HoakyClass : IHoakyService
  {
    public string HoakyMethod()
    {
      return HoakyNonAccessibleMethod();
    }

    string HoakyNonAccessibleMethod()
    {
      return "This is a hoaky method.";
    }
  }
}

Microsoft's recommendation is to restrict your Service Contracts to interfaces because it defines the group of operations and
the operation signatures. Let's read between the lines here. A group of operations is basically the interface's methods, and the operation signatures are well the method signatures. Nothing difficult about that now is there?

The other benefits of using interfaces for Service Contracts are that they can be extended by other interfaces.
You can also create classes that implement multiple service contract interfaces whereas a class can only implement one service contract. Versioning becomes easier because old clients can still point to the old service contract interface while newer clients can point to a newer service contract interface.

Pass By Value

You're parameters and return values represent the method signatures or operation signatures. The biggest thing to understand with WCF is that everything is pass by value or as I like to say "pass by copy". This is actually standard in many interoperable applications.
The next biggest thing to remember is that both parameters and return values must be serializable(convert to XML). Windows Communication Foundation (WCF) uses the DataContractSerializer as its default serialization engine to convert data into XML and to convert XML back into data.
The following datatypes are handled by the DataContractSerializer:

Primitive types such as integers and strings
Simple composite types such as DateTime
XML-based types such as XmlElement
Collections
Enumerations
Types marked with the SerializableAttribute attribute

For more information see: Types Supported by the Data Contract Serializer

Note to VB programmers: The value of the parameter names in the operation signature are part of the contract and are case sensitive.

It is possible to change the exposed name of your return values and parameters. You would use the MessageParameterAttribute attribute as follows:

using System;
using System.Collections.Generic;
using System.ServiceModel;
using System.Text;

namespace MyHoakierService
{
  [ServiceContract(Namespace="http://localhost/HoakierService")]
  public interface IHoakierService{
    [OperationContract]
    [return:MessageParameter(Name = "HoakyOut")]
    string HoakyMethod([MessageParameter(Name = "HoakyIn")]string input);
  }

On to Data Contracts

Wait, we had service contracts and now we have data contracts? Well we just mentioned that WCF methods work on a Pass By Value or "pass by copy" method. Why do we need data contracts? Ok, data contracts make an operation more widely accessible by a variety of clients. In other words, it's more interoperable.

We implement data contracts by simply marking our types with DataContractAttribute and DataMemberAttribute attributes. Data contracts are opt-in contracts. You have to apply the data contract attribute for them to be serialized.

using System;
using System.Runtime.Serialization;

namespace myHoakyService
{

[DataContract]
public class Hoakster
{
    // Step 1: Serialize a memeber.
    [DataMember]
    internal string HoakyName;

    // Step 2: Serialize a private member.
    [DataMember]
    private int HoakyNumber;

    // Note: No DataMemberAttribute = No seralized data.
    private string HoakyNonSerialized;

    // Note: Not serialized
    private string HoakyNonSerializedValue;

    //Step 3: serializing a Property that accesses a non-serialized member.
    [DataMember]
    public string HoakySeralizedValue
    {
        get { return HoakyNonSerializedValue;}
        set { HoakyNonSerializedValue = value; }
    }
}
}

Be aware, you're not limited to using Datacontract attributes and primitives. You can use other serialization methods as explained here: Specifying Data Transfer in Service Contracts (Some interesting stuff in there about Message Contracts which I'll cover in another post.)

Message Exchange Patterns

Service operations are supported by a SOAP message exchange that transfers application data back and forth,
including the data required to support standard security,
transaction, and session-related features.
This being the case, the service operation signature dictates a certain underlying message exchange pattern (MEP)
that can support the data transfer and the features an operation requires. Note that now an operation signature is building up to include security, transaction, and session data.

There are three patterns in the WCF programming model that you can use.
The request/reply is just like it sounds. A client sends a request with parameters and waits for the server to reply with a return value. Note that the return message/value could be an empty message as a result of a void return on an operation.
Another return type would be a Soap FaultException that notifies the client of an error.

A one-way operation is one in which a client invokes an operation and continues processing after WCF writes the message to the network. Note that the client wouldn't be processing any FaultException errors returned to it. To designate an operation as one-way apply the OperationContractAttribute with a IsOneWay=true property.

[OperationContractAttribute(IsOneWay=true)]
void hoakyMethod(string HoakyInput);

A duplex pattern allows the service and the client to send messages to each other independently whether using one-way or request/reply messaging. This works well for asynchronous operations or services that have to notify a client with a message. When you design a duplex contract, you design two interfaces; one interface to send messages from client to service and a callback interface to send messages from the service to the client.

You start by declaring your ServiceContract on your receiver interface (the one that the client sends the messages to). You add a CallBackContract property that points to the callback interface. And yes, this implementation tells the client "Hi Hoaky Client".

//Step 1: Define your ServiceContract for the receiving interface.
[ServiceContract(Namespace = http://localhost/MyHoakyDuplexService, 
                 SessionMode=SessionMode.Required,
                 CallbackContract=typeof(IHoakyCallback))]
public interface IHoaky
{
    [OperationContract(IsOneWay=true)]
    void Hoaky();    
}
// Step 2: Create a callback interface so the service can say something to the client.
// This defines the methods that the service can call on the client. So yes, if your client
// needs to hear from the service, it must implement this interface.
public interface IHoakyCallback
{
   //Note: We're still using the OperationContract attribute. 
   //This time we're using the OneWay 
   //property so the operation can talk in a one way direction.
    [OperationContract(IsOneWay = true)]
    void HoakyCaller(string hoakified);
}
//Step 3: Create a Class that implements the Service Contract Interface
[ServiceBehavior(InstanceContextMode = InstanceContextMode.PerSession)]
public class HoakyService : IHoaky
{
    string hoakified;
    IHoakyCallback callback = null;
    public HoakyService()
    {
        hoakified= "Hi Hoaky Client";
        //Note: The following allows the service to call a method on the client.
        callback = OperationContext.Current.GetCallbackChannel<IHoakyCallback>();
    }
    public void Hoaky()
    {
        callback.HoakyCaller(hoakified);        
    }
}

Security

You have 2 choices. You can set the secuirty of your message in the binding of the endpoint or you can turn off the message security in the binding. In most cases your system level settings will take care of what you need. Only in special circumstances would you set specific message protecting in the binding of an endpoint for specific messages.

There are more topics to cover but I think I'll leave those topics to another post.

Trouble in Paradise or Quick Find to the Rescue

Desirea Herrera — Wed, 03 Dec 2008 05:17:15 GMT

So I was working on this Windows Communication Foundation tutorial. The tutorial came as a pre-existing solution that you would update via WCF tasks. I'd successfully done the C# version after many attempts. Most of my problems stemmed from typos during the tutorial. Then came the VB version of the tutorial. Well, there actually wasn't much VB or C# in the labs so I can't use the excuse that I work mostly in C#. That sucks.

So what was the error? I kept running the lab and got an error that the Internet endpoint did not exist. I'd run it several times. Well as it turned out, I had a typo buried inside of the app.config file. A quick Find for the errored address allowed me to pinpoint the error of my ways.

Sometimes you just can't beat a good quick search of your project. And so, being your own spelling police really can save the day.

What is Windows Communication Foundation?

Desirea Herrera — Mon, 01 Dec 2008 20:25:26 GMT

What we're looking at is at it's basic level a Service Oriented Architecture. It basically allows you to write services for other applications to use. It combines COM, COM+, and MSMQ, .NET Remoting, ASMX, System.Messaging, and .NET Enterprise Services. The basic concepts of interoperability, performance, transactional support as well as security differ from client application to client application. WCF strives to meet the needs of different client applications.

Basically a WCF client and a WCF service use the WCF which addresses communication challenges between a service and a diverse range of client requirements. Microsoft identifies the following as the most important aspects of WCF:

Unification of existing .NET Framework communication technologies.
Support for cross-vendor interoperability, including reliability, security, and transactions.
Explicit service orientation.

WCF can communicate via Web Services using SOAP or messages like RSS. The ability to communicate using SOAP enables WCF to communicate with a wide variety of clients which are not necessarily built using WCF. I found it highly interesting to come across WS Specifications which are used to add security features, end-to-end reliability, and transactional support to the SOAP message.

Microsoft did some performance testing to compare it to .Net relevant technologies. (go.microsoft.com/fwlink/) With WCF configured using BasicHttpBinding, the throughput performance of WCF was better than ASP.NET Web Services by 19%, 21% and 36% for 1, 10 and 100 objects in a message, respectively. When both operated over HTTPS, WCF outperformed ASP.NET Web Services by 16%, 18% and 26% for 1, 10 and 100 objects in a message respectively. The results when compared to Web Services Enhancements was even better. .Net Enterprise Services and .Net Remoting showed similar improvements in performance.

Installing WCF won't break pre-existing applications built in any of these .Net technologies. You do have to be aware of some interoperability issues with the WS specficiations. Migrating WSE 3.0 Web Services to WCF

Messaging

WCF is based on message passing communication. Messages of any type can be uniformly represented which means that WCF can utilize a single API across a variety of transport methods. In WCF terms, a client sends a message and a server responds to messages. Endpoints are points of contact for both services and clients. They describe in a standard-based way where messages should be sent, how they should be sent, and the messages format. A service might have multiple endpoints for different purposes. A client's endpoint would be compatible with one of the service's endpoints.

In a larger picture, you can think of a service as a sort of communications center. It would accept calls from cell phones, telephones, and maybe even email. On the other hand, each of those devices/applications only interact with one endpoint on the communications center.

At the core of any communication is the transport protocol. These can range from HTTP to TCP and those that support MSMQ nodes on a Peer Network. WCF is extensible so you can add more transport mechanisms as needed.

WCF natively supports the following message formats but is also extensible in this respect:

Text encoding, an interoperable encoding.
Message Transmission Optimization Mechanism (MTOM) encoding, which is an interoperable way for efficiently sending unstructured binary data to and from a service.
Binary encoding for efficient transfer.

WCF also supports messaging patterns as pertains to each message format.

The easiest way for the beginner to think of WCF is to think of it as a large switchboard. Behind the switchboard are different functions that need to be reused by a variety of customers. Each customer might speak a different language and use different devices like a cell phone, a VoiP application, or a telephone. The WCF switchboard has endpoints configured that each of these customers can use to send messages to which the WCF switchboard responds.

For more fundamentals of WCF, I suggest the following article from Microsoft : Fundamental Windows Communication Foundation Concepts

And this is just the beginning...

Unit Testing in Visual Studio

Desirea Herrera — Mon, 01 Dec 2008 08:50:39 GMT

The more I learn, the more I know I don't know. As an MCT, it's my job to continually update my skills. To that end, I've been delving into things that aren't covered in the courses I teach. Things like Unit Testing.

What's A Unit Test?

With Visual Studio 2005 and 2008, you get the ability in some versions like Team System to create a Test Project to do Unit Testing. Before I start talking about creating a unit test, let's review the basics. A unit test verifies that a function actually performs it's duties. Now, there are black box and white box types of tests. A black box test only tests that a function accepts only the datatypes it's designed to accept and returns the data or no data that it's expected to return. In other words, you put in certain stuff and get certain stuff back. Now a white box test actually allows you to know what's going on between the input and output. White box testing ensures that you actually are testing all code pathways. It's called "Code Coverage". For more information about Unit Testing you can check the following links:

It's important to write your Unit Tests before you actually develop your application. After identifying the requirements of the application, a unit test can define the functionality of different pieces of the code before it's written. Unit testing helps to maintain the integrity of your code during refactoring. You'll always be able to test that the function still fulfills it's intended purpose.

Generating a Unit Test in Visual Studio

The simplest method of generating a unit test in Visual Studio is to right click the name of any method and select Create Unit Tests. Be aware that not all versions of Visual Studio support Unit Testing. You can also create a new Test Project to add to the project and then, a test class can be added by either selecting from Add New Test popup or by selecting Unit Test from Add menu. This brings up the Create Unit Tests screen where multiple methods to be tested can be selected.

Visual Studio only actually writes a basic stub for the Unit Test. It's up to you to fill in the blanks for the application. You'll do things like test that the return values are the correct datatype and within the expected value range. You'll also check to make sure the funciton only accepts the data it's suppose to accept.

You'll normally see the following assert statement:
Assert.Inconclusive("A method that does not return a value cannot be verified.");

If you ran the Unit Test for the method you're testing right now, You'd see the error message "Assert.Inconclusive failed. A method that does not return a value cannot be verified." Now, if you comment out the Assert.Inconclusive statement, you'll have a test that passes because the unit test method isn't testing for anything. That's not going to help.

You'll have to write some test code with the Assert statement. You'll be supplying the method with specific values and comparing the results with the expected result in an Assert statement.

Unit Test Design is Obviously Important

Obviously, did I say that again? Yup, I did. You've got to think of all possibilities going into the method and all coming out of the method. This takes some prior planning. Now it might seem backwards based on what I've just said about right clicking a method and/or creating a Test Project to add to your application. The key is to think out your Unit Tests ahead of time so that you can implement them easily using Visual Studio.

Additional Resources

Good Luck Unit Testing

I've written an additional Unit Testing Review with more links @ Unit Testing Review List