Microsoft Testing framework (Microsoft.VisualStudio.TestTools namespace) overview

If you are working within .Net and other MS's platforms, you probably should be happy having Visual Studio Team System as part of Visual Studio IDE. This is getting more interesting if your ALM is Team Foundation Server as Visual Studio with TFS perfectly fit and compatible(can't be different?)

What I like - is detailed useful and thought-out Team Test API. Yes API! This is presented within 5 namespaces (references are here):
Microsoft.VisualStudio.TestTools.LoadTesting
Microsoft.VisualStudio.TestTools.UnitTesting
Microsoft.VisualStudio.TestTools.UnitTesting.Web
Microsoft.VisualStudio.TestTools.WebTesting
Microsoft.VisualStudio.TestTools.WebTesting.Rules

Besides of API, VS Team System provides GUI User-friendly tools for managing test sets, code edition within VS IDE (with all native capabilities) and record-playback feture. Supporting several languages running over CLR is also benefit of testing framework from Microsoft.

One more important thing is Load testing pure functionality as part of Test Team API (performance/load modeling, profiling, watching performance counters, monitoring DB productivity and so fort) and all that goes with VS license!

The Getting Started page of Unit Testing framework can be found on this MSDN's page. As ususal in unit testing, API from MS gives various assertions, implemented within few classes. I found interesting and most useful from my standpoint, the following classes and theirs polymorphic assertions methods:
Assert, StringAssert, CollectionAssert, AssertFailedException
The polymorphic approach of assertions afford the abstract interface which ease programming by datatype independency. It means proper implemntation of a particular data type is an internal thing and yuo should not care about that, as well as type trating, code and workflow safety, error and exception handling, reporting. Check out the benefit, for example from overloading list of Assert.AreEqual

Data-driven testing (DDT) is mostly implemented as data native agnostic model and I found that DDT is provided in 2 classes: DataSourceElement and
DataSourceAttribute. If you need to process details of a particular test, just instantinate an object of TestContext


To understand a standart unit test workflow, check out the excerpts (from MSDN):

the original calss implementation

using System;

namespace SampleClassLib
{
public class DivideClass
{
public static int DivideMethod(int denominator)
{
  return (2 / denominator);
}
}
}

the testing code is

using Microsoft.VisualStudio.TestTools.UnitTesting;
using SampleClassLib;
using System;
using System.IO;
using System.Windows.Forms;

namespace TestNamespace
{
[TestClass()]
public class DivideClassTest
{
[AssemblyInitialize()]
public static void AssemblyInit(TestContext context)
{
MessageBox.Show("Assembly Init");
}

[ClassInitialize()]
public static void ClassInit(TestContext context)
{
MessageBox.Show("ClassInit");
}

[TestInitialize()]
public void Initialize()
{
MessageBox.Show("TestMethodInit");
}

[TestCleanup()]
public void Cleanup()
{
MessageBox.Show("TestMethodCleanup");
}

[ClassCleanup()]
public static void ClassCleanup()
{
MessageBox.Show("ClassCleanup");
}

[AssemblyCleanup()]
public static void AssemblyCleanup()
{
MessageBox.Show("AssemblyCleanup");
}

[TestMethod()]
[ExpectedException(typeof(System.DivideByZeroException))]
public void DivideMethodTest()
{
DivideClass target = new DivideClass();
int a = 0;
int actual;
actual = target.DivideMethod(a);
}
}
}

If the shown snippets are not clear why and how, study the Structure of Unit Tests page

Looks like everything in the box.
AND one more interesting feature in .Net Reflection - thus testers and developers see internal staff of implementation, such as all properties and methods of UI control and so forth. Btw, using that test code basic verification testing (aka baseline) can be generated on fly