views:

47

answers:

2

I have a test setup where I have many very similar unit tests that I need to run. For example, there are about 40 stored procedures that need to be checked for existence in the target environment. However I'd like all the tests to be grouped by their business unit. So there'd be 40 instances of a very similar TestMethod in 40 separate classes. Kinda lame. One other thing: each group of tests need to be in their own solution. So Business Unit A will have a solution called Tests.BusinessUnitA.

I'm thinking that I can set this all up by passing a configuration object (with the name of the stored proc to check, among other things) to a TestRunner class.

The problem is that I'm losing the atomicity of my unit tests. I wouldn't be able to run just one of the tests, I'd have to run all the tests in the TestRunner class.

This is what the code looks like at this time. Sure, it's nice and compact, but if Test 8 fails, I have no way of running just Test 8.

  TestRunner runner = new TestRunner(config, this.TestContext);

  var runnerType = typeof(TestRunner);
  var methods = runnerType.GetMethods()
     .Where(x => 
       x.GetCustomAttributes(typeof(TestMethodAttribute), false)
       .Count() > 0).ToArray();

      foreach (var method in methods)
      {
       method.Invoke(runner, null);
      }

So I'm looking for suggestions for making a group of unit tests that take in a configuration object but won't require me to generate many many TestMethods. This looks like it might require code-generation, but I'd like to solve it without that.

A: 

Can you use Data Driven Tests? http://msdn.microsoft.com/en-us/library/ms182519(VS.80).aspx

You can then exclude rows that previously passed...

JLNazario
I dunno, looks different than what I'm doing. I need to run the same test (essentially) but share it among many projects. So Data driven tests are similar except for the project-crossing thing that I'm doing.
jcollum
Data driven tests would be the way to go. They're a bit clunky in MSTest but they should still be able to do the job.The data to pass in to the test will be the name of the sproc you are checking the existence of. And obviously you'll need multiple data driven tests if you're going to be splitting them across multiple test assemblies - I'd look to making one common method that each test assemblie makes calls to to keep the code DRY.
Richard Banks
A: 

My solution to this was to put all the tests in their own assembly, decorate them with attributes then reflect through the assembly to execute the tests. Made more sense than data driven tests.

jcollum