After writing unit tests for awhile, you will observe there are common patterns and common needs.  One way to fulfill some of these needs is to use a “test base class” or an “abstract test class”.  Using such a pattern for MSTest can help you create more robust unit tests with less code.

The concept is pretty straight forward.  Basically, create a base class that can perform some mundane or defensive programming tasks for you.

In MSTest, this is accomplished by create a new class (or unit test class) in either your test assembly or a common assembly (that is also a test assembly).  You cannot make it truly abstract (that leads to some funkiness), but you can inherit from in when you create a new unit test class by decorating it with the TestMethod attribute.

You can push the typical TestContext property up to a base unit test class, as well as provide virtual methods for TestInitialize and TestCleanup.

Things to think about for you Test Base class:

·         Mock out items and clean up all your mocking

·         Clean up your dead files

·         Add support methods to copy test files

using System;
using System.Text;
using System.Collections.Generic;
using System.Linq;
using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace TestSupport
{
    /// <summary>
    /// Summary description for UnitTest1
    /// </summary>
    [TestClass]
    public class TestBase
    {

        private TestContext testContextInstance;

        /// <summary>
        ///Gets or sets the test context which provides
        ///information about and functionality for the current test run.
        ///</summary>
        public virtual TestContext TestContext
        {
            get
            {
                return testContextInstance;
            }
            set
            {
                testContextInstance = value;
            }
        }

        [ClassInitialize]
        public static void MyClassInitialize(TestContext testContext) { }

        [ClassCleanup]
        public static void MyClassCleanup() { }

        protected bool _testInitializedRan;

        [TestInitialize]
        public virtual void MyTestInitialize()
        {
            _testInitializedRan = true;
        }

        [TestCleanup]
        public virtual void MyTestCleanup() { }
    }

    [TestClass]
    public class MyTestClass : TestBase
    {
        [TestMethod]
        public void ShowsThatTestInitializeRan()
        {
            Assert.IsTrue(_testInitializedRan);
        }
    }
}

I'm putting on a two day training session for a group where some participants might be completely new to unit testing and/or TDD.  Almost all are new to TFS.  I put together a survey for the participants to gauge my audience.  I thought this might be a useful resource for others for looking into training, thinking about training or perhaps even job interview material.  Here it is in its raw format directly from the survey engine.

You still can't run compact framework unit tests in Team Foundation Build very easily.  <ShamelessPlug>You'll be able to with TFS Advantage - Compact Framework Edition</ShamelessPlug>  Anyway, you would think you could compile them consistently though, right?

Well, that's not always the case.  I was helping out Chris Tacke of OpenNETCF with a problem he was having with build failures on solutions that contained:

• Compact Framework (CF) projects
• Compact Framework unit test projects
• MSTest private accessors
• Were participating in a continuous integration process under Team Foundation Build using Microsoft Team Foundation Server.

He has had success with all of these technologies independently, but when combined together, it went boom!  You know when a problem mentions four different technologies it's always a fun one to solve. ;-)

The Setup

Chris has CF projects, CF unit test assemblies, some private accessors and he submits to the build.  The build fails with "API restriction".

Here's the error:

What's going on here?  I don't know exactly, but I've got some bits and a workaround.

The BuildShadowTask is a component used by the Microsoft.TeamTest.targets used to build the private accessor DLL (e.g. myproject_accessor.dll) that a unit test uses to get at private and protected members of a test target.

It in turn calls the Publicize.exe executable to do the actual work.

A bit more on Chris Tacke's scenario.  He's taken one of my patterns and created a TestClassBase that does some common initialization, cleanup and provides some test specific helper functions.  This has been put into a CF unit test assembly that has no real unit tests in it.  Since it has no real unit tests in it, it has no private accessors in it either.

This was essentially the item that triggers the downfall, albeit, he wasn't doing anything really wrong.

It appears that when MSBuild, BuildShadowsTask and Publicize do their work, they're pulling in some copy/version of Microsoft.VisualStudio.SmartDevices.UnitTestFramework from somewhere else besides where the rest of the MSBuild process is going to get it from.  And, somehow it is being kept in the same AppDomain as the rest of the MSBuild process.  (So, I doubt that it is publicize.exe that's the problem).  Or vice versa, MSBuild is pulling one in and then BuildShadowsTask is attempting too as well.

The Workaround

If you are going to use private accessors in any compact framework unit test assembly in your solution, use it in all compact framework unit test assemblies.  Even if you have to refer to something you don't need to make a private accessor.  Even if you create a "shill target" assembly, you need to have in it in all of them.

Also, we had previously attempted to overcome the inability of Team Build to find the Microsoft.VisualStudio.SmartDevices.UnitTestFramework.dll by registering it in the GAC.  As always, when you mess with fire you get burnt.  At this point, I have had Chris has add the following to his build scripts (update the path as appropriate to find Microsoft.VisualStudio.SmartDevices.UnitTestFramework.dll)

<ItemGroup>

<AdditionalReferencePath Include="c:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PublicAssemblies\" />

I have uploaded some code snippets to download that use some of my common patterns for unit testing using MSTest.  Some are Typemock centric.  Some depend on helper methods which are unpublished; implement in your own code or delete the references to them.  They're not polished for release by any means, but you may find them useful. 

Here's a quick list of what's in there.

       <Title>Unit Test For ctor</Title>
      <Shortcut>utc</Shortcut>
      <Description>Code snippet for a ctor unit test.</Description>

      <Title>Property = null</Title>
      <Shortcut>utpn</Shortcut>
      <Description>Code snippet for unit test to test setting a non-nullable property to a null value.</Description>

      <Title>Unit Test A Property</Title>
      <Shortcut>utp</Shortcut>
      <Description>Code snippet for unit test to test a property</Description>

      <Title>Unit Test</Title>
      <Shortcut>utcp</Shortcut>
      <Description>Code snippet for unit test to test a ctor that accepts a value that sets a property.</Description>

      <Title>Property = (argument out of range)</Title>
      <Shortcut>utpiv</Shortcut>
      <Description>Code snippet to unit test setting a property to an invalid value and receiving a ArgumentOutRangeException.</Description>

      <Title>Unit Test a method on a target.</Title>
      <Shortcut>utm</Shortcut>
      <Description>Code snippet to unit test a method on the target.</Description>

      <Title>Typemock Recorder Block</Title>
      <Shortcut>rx</Shortcut>
      <Description>Code snippet for a recorder block for TypeMock</Description>

Third Party Software

Unit Testing

Single Directory Compilation

It takes a little more upfront work, but I recommend (especially for managed assemblies) to adopt a single output folder strategy.  (this might be trickier with unmanaged C++) I do this for a number of reasons:

• Non referenced (or loosely coupled assemblies) will be available to other assemblies.  In other words, if I have a assembly I build and its pulled into the application at run time, but nothing references directly as a project, it will be there from the last compilation.  This negates a manual copy/paste operation, or monkeying with post build events in the projects.
• It’s faster – quite simply, if you do this and set “Copy Local = false”, the compiler/operating system doesn’t have to copy and move all of your referenced assemblies around to keep the dependent assemblies up to date.  It builds it into the obj directory, puts a copy into the output, and that’s it.  In a larger solution of 100 projects with tons of references and a large dependency tree, compile times skyrocket.  This mitigates that problem.
• You always know where your outputs are and can quickly see what is up to date and what’s not.
• You can do a “hard clean” (Shift-Del) REAL easy.
• Oh, and it’s the way the build server is going to build your software anyway, so when you look like the build server, the build server becomes your friend, not your enemy.  Some hinky problem that might come up in the build will more than likely produce itself on your box, before you check in. My trick to doing this is to prefix your <OutputPath> value in your project files with the $(SolutionDir)property (macro), and subsequently your project templates (located in a path similar to C:\Users\tim\Documents\Visual Studio 2008\Templates\ProjectTemplates ) to have the following.  This automagically puts into a single directory compilation strategy.  It does NOT set your CopyLocal = false.  

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> 

<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>false</Optimize>
<OutputPath>$(SolutionDir)\bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>

</PropertyGroup>

Monitoring The Build

• The build explorer is available from the Team Explorer right in VS.net. 
• If you install the Team Foundation Server Power Tools (highly recommended), you can run the Build Notification tray app.
• Project Alerts – will email you the results of every build.  I have an Outlook rule that moves the successful ones to a subfolder and leaves failed builds in my inbox.

I was completing an installation of a single-tier TFS system today.  Another contractor thought he was going to just get it installed with a click-click-next-next.  Anyway, to make a long story shorter, the SQL Server install was completely wrong to meet the TFS needs.  So, my inclination was to re-image the server, but that would not be available until the next day.  Relunctantly, I opted to do an uninstall/reinstall of SQL Server.  I have tried this in the past to no avail.  Today would be different, right?  Yes and no.

 The SQL Server reinstall went pretty good.  I got through 80% of the TFS install when I get this message:  Error 29105.Team Foundation Report Server Configuration: The SQL Reporting Services databases were not created.  Retry?

Someone made the C: drive 2 GB on this server;  I don't know why, but it is.  Has this killed me?  Oh no, six hours of work down the drain, just when I was feeling pretty good!

Nope.  Turns out, SQL Server leaves the database files in place when you uninstall it.  This makes sense.  The reporting files are still there and the install does not want to overwrite them.

In my case, I got it install by deleting the following files from the SQL Server data directory.

I needed a component that would examine a directory and find all test assemblies in a directory.  This sounded like a job for LINQ.

var allFiles = from fileName in Directory.GetFiles(directory.FullName, "*.dll")
let assembly = Assembly.LoadFile(fileName)
let types = assembly.GetExportedTypes()
from Type t in types
where t.GetCustomAttributes(typeof(TestClassAttribute), true).Length > 0
select assembly ;

The above LINQ query will:

1. Get all DLL (assemblies) files.
2. Use the *non-preferred* way to load each of the files as an assembly using Assembly.LoadFile()
3. Reflect all the public types in the assembly using Assembly.GetExportedTypes()
4. Retrieve an array of any TestClassAttributes from each type and check to see if there are any
5. Put the results of into an IEnumerable<Assembly>

Using this above, in a single statement, I have a managable list of all assemblies in the directory that have a least on MSTest test class in them.