In Visual Studio, is there a way to generate unique method names automatically?

Question

I'm writing a bunch of tests for a class, and frankly I don't want to go to the effort of naming each test intelligently: "Compare2002to2002forLessThanOrEqual"

I'm cool with TestMethod1 through TestMethod120 - but I've got to edit each name, and that gets annoying. Is there any plugin that will generate unique names for all the methods in a class tagged with the [TestMethod] Attribute?

Answer 1

It's not entirely clear what feature you want here. How would you envision that this name is generated? Are you looking for the editor to spit a method name as soon as you type [TestMethod]?

If so such a feature does not exist in Visual Studio today.

Answer 2

You could create a code snippet that fills out most of the name. Something like this:

<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/CodeSnippet"&gt;
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title></Title>
      <Description></Description>
      <Author></Author>
      <Shortcut>test</Shortcut>
    </Header>
    <Snippet>
      <!-- Add additional Snippet information here -->
      <Declarations>
        <Literal>
          <ID>val</ID>
          <ToolTip></ToolTip>
          <Default>val</Default>
        </Literal>
        <Literal>
          <ID>condition</ID>
          <ToolTip></ToolTip>
          <Default>condition</Default>
        </Literal>
      </Declarations>
      <Code Language="CSharp">
        <![CDATA[ [TestMethod] public string Compare$val$to$val$for$condition$
                    {

                    } ]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>

Answer 3

If you are writing distinct test methods from scratch then the naming of the method should not be a great overhead. This suggests that you may be copy-and-pasting the test method and changing some values and perhaps violating the DRY principle. If this is the case would it not be better to refactor the tests with an abstraction, leaving you with fewer methods (perhaps even one) and then provide a set of test conditions that the method could iterate over?

A benefit of this could be that if the interface or functionality of the module you are testing changes, you need only change the single test method instead of many.