With the advent of unit testing infiltrating more of and more development groups and continued growth in both new software and quality expectations, the management of tests can become quite a complicated issue. Do I use Word? Excel? TestDirector? Custom? But regardless of the path you take, there is a common item you need to consider. Just what are you going to call your actual tests.

The two basic rules I follow when naming a test are

  1. The name must be unique
  2. The name must be meaningful

The uniqueness rule is pretty obvious both in rationale and implementation. A test’s usefulness is decreased if test and development cannot have a discussion about it and not know for certain that they are talking about the same thing. It also makes reporting a pain if you have duplicate test names and they had different results.

Making test names meaningful is a bit more tricky and requires both up-front planning and ongoing maintenance.

Every application can be broken down into smaller parts (modules), and your application cannot, I counter with “you need to rethink your understanding of your application”. According to Watts Humphrey, a 3 or 4 million line application can be usually broken down into 4 or 5 layers of these modules somewhat like this (the names are mine):

  • application
    • massive module
      • major module
        • minor module
          • feature

At this point, your exercise is to do a quick draft of this type of layout for your application. it does not have to be complete, or completely accurate. A representative approximation of what we are going for here. Note: When you go to do this for real, this needs to be accurate, so consult with a couple developers and compare their answers to get an idea of things. If you ask only one you risk that they do not actually know the structure correctly. Getting multiple answers limits that possibility somewhat.

Done? Great. As you can (hopefully) see, this gives us a nice architectural overview of how the application is logically structured. The next step is to assign a unique abbreviation to each component identified in your tree. I would suggest at least two letters long, and a max of 5. The abbreviations should try to closely represent what they are for, but that might not be possible in huge applications. But that is okay as what we are going for here is uniqueness. Even the oddest name->feature mapping will be understandable after some usage.

  • application – app
    • massive module – mass
      • major module – maj
        • minor module – mnr
          • feature – feat

The next step is to make an executive level guess as to how make tests your largest feature will be, in terms of number of digits. For example, feature is thought to have more than a thousand tests, but less than 10000, so the number of digits is 4. (Even if this number is wrong, you can just add another digit no problem?
|

it just makes sorting a pain — unless you whip together a script which renames all your tests of course)

The final step in naming a test is to merge everything that we have done thus far to actually name a test, separated by a _ (I suppose you could use CamelNotation, but I think that is hard to read when dealing with the sort of scale large applications present). What we end up then for the first test of a feature is app_mass_maj_mnr_feat_0001 and the final on is app_mass_maj_mnr_feat_9999.

And just like magic, you have a highly scalable (add more modules/features where appropriate) naming convention that uniquely identifies a test, and gives each test a context. This type of convention also helps you make intelligent decisions about what to test when. If a minor module has changed, you might need to test all the features under it, but not those under another module for instance.