Visual Studio Team Test provides a set of asserts through three classes:  Assert, StringAssert and CollectionAssert (all defined in Microsoft.VisualStudio.TestTools.UnitTesting namespace). All of them contains a long list of static methods to test several different kind of data in different ways.
Even if there is a huge number of methods, there are many scenario that aren’t still covered. Let's see a simple example. We need to test if two instances of the same class are equals (contains the same data). Let's see the basic class:

public class MyClass
{
    public MyClass(int intProp)
    {
        this.intProp = intProp;
    }

    public int IntProp
    {
        get { return intProp; }
        set { intProp = value; }
    }

    private int intProp;
}

Here is our test case:

Assert.AreEqual(new MyClass(12), new MyClass(12));

Executing the above test we will get a failure: "Assert.AreEqual failed. Expected:<MyLib.MyClass>, Actual:<MyLib.MyClass>".

Why they aren’t equals? We are comparing tow different pointers, simple! Ok, but this isn’t the subject of the post, so, I’ll go ahead.
In order to make the test case succesfull all you need to do is to override the method Equals in MyClass:

public override bool Equals(object obj)
{
    if (!(obj is MyClass))
        return false;

    return ((MyClass)obj).intProp == intProp;
}

I execute again and it works. Is this enough? Not really. Lets consider another test case:

Assert.AreEqual(new MyClass(14), new MyClass(12));

The test will fail as expected producing the following error message “Assert.AreEqual failed. Expected:<MyLib.MyClass>, Actual:<MyLib.MyClass>.”

Not really clear what’s wrong here. We would have some more clear idea of what are the differences, since we are testing with Assert.AreEqual. The idea is to implement a custom assert. An assert class is nothing more than a class with a bunch of static methods that checks the parameter values. If something is not correct (assertion not satisfied), they throws an exception (AssertFailedException). So, in our basic sample we would have something like:

public class MyClassAssert
{
    public static void AreEqual(MyClass expected, MyClass actual)
    {
        Assert.IsNotNull(expected);
        Assert.IsNotNull(actual);

        if (expected.IntProp != actual.IntProp)
        {
            throw new AssertFailedException(
                string.Format(
                    "MyClass.IntProp values are different.{0}Expected: {1}, Actual: {2}",
                    Environment.NewLine,
                    expected.IntProp,
                    actual.IntProp));
        }
    }
}

Applying the above assertion to our test case:

MyClassAssert.AreEqual(new MyClass(14), new MyClass(12));

We will get a more clear error message:
"MyClass.IntProp values are different.
Expected: 14, Actual: 12"

Ok, the sample is super simple and it doesn’t make too much sense, but it give an idea of how to implement custom assertions for more complex ‘real’ types providing meaningful test messages.