Exploring the Unit Test Generator VS Extension v1.RC

  • Article

We are busy with final signing of the Unit Test Generator release candidate (RC), previously discussed in Unit Test Generator under the bonnet (hood) … aka vsarUnitTestFx ...‎ and Announcing the Unit Test Generator Visual Studio Extension BETA‎. In this post we will take a peek at some of the features to clarify some of the common questions we have been receiving from dog-fooding users.

Please keep an image on Visual Studio ALM + TFS Blog for the release notification for the Release Candidate (RC).

The team’s project principles

Let us review our project principles:

  1. Our solution won't resurrect the old command.
  2. It must support .NET MS-Test and generate VB/C# test code.
  3. It must achieve a moderate amount of restoration of Dev10 feature functionality.
  4. Our solution to this problem should be a "reference implementation" of how to do this for a particular test framework.
  5. It could provide the basic infrastructure and an extension point, but this is not a must.
  6. It should focus on project and reference management and not on code generation.

The good news is that with the upcoming v1 release, team achieved all six principles.

Basic test generation
Q1: What happens by default?

  • Start by creating a very simple class library, containing a public class and no methods.
  • Right click anywhere on the class body.
  • Peruse the context menu and notice that the Generate Unit Test feature does not light up.
    image
  • In the ALPHA and BETA release the feature lit up and allowed you to create an empty test class.
  • In the final release we require a public class and at least one public method, before the Generate Unit Test feature lights up.

Next we add some rudimentary code to the class:

  1. We add two public methods, one protected method, one private method and one public operator.
  2. Note that we only have the UnitTestGeneratorDemo project and this point.
  3. When we right click in the class body, notice that the Generate Unit Test feature lights up.
    Note that clicking within the body of a method limits the generation to the method in context, whereas clicking in the class body instructs the Unit Test Generator to iterate through all methods of the class.

image

Select the Generate Unit Test feature.

  1. The default behaviour is to create a test project, containing one test class and a test method for each public method of the class.
    Appropriate assemblies are referenced, i.e. UnitTestFramework, and each test method contains an Assert failure statement.
  2. Private and protected methods are ignored in v1 by design.
  3. Operators, even if public, are ignored in v1 by design.

image

The configuration dialog
Q2: Can I change the test code output?
Q3: Can I force each test method in its own class?
Q4: Can I change the test code output ad-hoc?
Q5: What are the known tokens?

Next we delete the generated test code from the project and the disk to start at the beginning.

Select the Configure Unit Test Generation feature from the Test menu. The configuration dialog allows us to select the MSTest, NUnit or XUnit test framework, an empty, exception or assert test method statement and tweak the project, class and tweak the method name formatting using static names and/or the [Project], [Class] and [Method] tokens.

image

Using the Configure Unit Test Generation dialog, try a few customizations:

  1. Select NUnit for the Test Framework

  2. Add [Method] to Class Name

  3. Select Throw NotImplementedException for the Method Body

… giving you:

image

At this stage we have the following known tokens at our disposal: PROJECT, NAMESPACE, CLASS and METHOD.

If you select the Show on each run checkbox, a configuration dialog will be presented with each Generate Unit Test request. This is useful to configure the unit test generation for each run, for example, if you want to test an area with NUnit and another area with XUnit.

Right click in the class body and select Generate Unit Test feature as before.  What is different?

image

  1. The using, assembly references and class/method attributes are adapted to match the test framework, in this case NUnit.
  2. The one line test code is changed from the default Assert to the throw new NotImplementedException().
  3. Each test method is placed in its own test class, caused by adding the [Method] token to the Class Name Format.

And there is lots more … but not today!

There are many other variations to experiment with … but we leave those to you  to explore Smile