After loading a test project with many tests in one class or an assembly, the IDE may respond slowly.  This will only occur if there are quite a few tests in one assembly ( > 2000 unit tests) or if there are an unusually high number of tests inside of one class ( > 500).  Depending upon the speed of your machine, these numbers can vary.  The reason for this is that we attempt to discover all of the test methods in a class upon certain events that are generated in the IDE.  For example: when you create a method inside of a class, the IDE generates an event to let us know the method and its signature.  Unfortunately, in Visual Studio 2008, instead of notifying us that a particular method has changed, the IDE is signaling that the entire type has changed.  Since we do not know which method has changed in this type, we are forced to rescan the entire type.  When a class has a large number of methods, this can take more time than is acceptable and may sometimes make the IDE appear as if it is not responding.

Solutions 

There are a few options that you can try to relieve these symptoms, please select the one that is most appropriate for your situation.

Reduce the number of unit tests in one single class by using Partial Classes:

When iterating through the methods of a class using reflection, the methods that show up are only the ones within the portion of the partial class that is being examined.  For example: When a user changes a method within a class, the IDE tells us that the type has changed and passes us a reference to that type.  When we iterate through that class, we only get the methods that appear in the definition of that type within the file that was changed.  This means that if you had a class definition like the following:

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

 

namespace ClassLibrary1

{

    public class Class1

    {

        public void Method1()

        {

        }

 

        public void Method2()

        {

        }

 

        public void Method3()

        {

        }

    }

}

 

With minimal effort, you could separate it into two different files and reduce the effect of the background discovery of test methods by moving some of the methods into a separate file.  The following class definitions show how the above referenced class was split into two partial class definitions.

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

 

namespace ClassLibrary1

{

    public partial class Class1

    {

        public void Method1()

        {

        }

 

        public void Method3()

        {

        }

    }

}

 

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

 

namespace ClassLibrary1

{

    public partial class Class1

    {

        public void Method2()

        {

        }

    }

}

 

Reduce the number of unit tests in one assembly:

This method reduces the effect of the background discovery of test methods by refactoring an assembly and separating test classes into smaller assemblies.  Depending upon the complexity of the assembly, this can take some work and may be more than you wish to undertake.

Disable background discovery of test methods: (Available in VS2008 SP1 only)

1.        Select the Tools | Options | Test Tools | Test Project menu option.

2.       On the Test Project dialog (figure 1.1), select the “Disable background discover of test methods” checkbox option and press ok.

This will disable the background discovery of test methods and will dramatically speed up the IDE.  However, since this is global option, this will disable the test method discovery on every project.  If you wish to re-enable the discovery, simply load the Test Project dialog again and deselect the “Disable background discover of test methods” checkbox option.

 

 

Figure 1 - Test Project Dialog