Unit Test Generator v1.2 and Tim’s Gremlins

The vsarUnitTestFx (Unit Test Generator) team has just finished the testing of the latest version of the extension v1.2.


Start exploring the extension by Exploring the Unit Test Generator VS Extension v1.RC.

v1.2 – What’s New?

Similar to v1.1 this latest release is a bug fix release, which resolves the bug “9205 - Configuration dialog does not appear by default as expected”.

  1. Right-click in the scope of a public class or method.
  2. Select the “Generate Unit Test” feature.
  3. With v1.2 you are now faced with the Create Unit Test Configuration Dialog.
  4. You can select whether to show the dialog on each run (default) or not. As before, you can also find the dialog in the TEST menu.


Tested Project Types

The test team validated the following project types as part of the regression and feature test suite:

  • Windows Store - Grid App
  • Windows Store - Class Library
  • Windows Store - Windows Runtime Library
  • Windows Store - Unit Test Library
  • Windows: Windows Forms Application
  • Windows: WPF Application
  • Windows: Console Application
  • Windows: Class Library
  • Windows: Windows Service
  • Windows: WPF Custom Control Library
  • Windows: WPF User Control Library
  • Windows: Forms Control Library
  • Web: ASP.NET Web Forms Application
  • Web: ASP.NET MVC 4 Web Application
  • Web: ASP.NET Server Control
  • WCF: WCF Service Library
  • WCF: WCF Service Application

Tim’s Gremlins

While Darren Rich is single handed driving Treasure Map development team to tears and has delayed the planned release of v2.1 with his phenomenal testing imageand tenacious push-back, we have anther star in the Unit Test Generator team. Tim Star has done in-depth code reviews, given Rob Jarratt candid feedback and completed multiple and comprehensive test runs. As a consequence, many of the issues resulting in the Unit Test Generator feature from not being available are referred to as Tim’s Gremlins Smile

Here are a few examples when the feature will be disabled

  • class is not public

  • class is public, but contains no public methods

  • class is public, but focus is on an operator

  • class is public, contains a public method, but the code has an issue, i.e. missing ()’s 


Difference between proof of concept and feature re-enablement!

We have received a number of feedback, ranging from “excellent feature” to “bring original feature” back, which necessitates a brief discussion of the teams objectives.

  1. The extension is not about feature re-enablement and the team intentionally did not use the old feature as a base or reference.
  2. The extension is based on features we highlighted during discussions with developers and testers. The core value seems to be in the generation of the test project, references and ability to choose the test framework, not the generated test stubs.
  3. The extension is a proof-of-concept, not a product. We are in the process of experimenting with concepts and principles and the extension may be considered small and incomplete.  Its evolution depends on your candid feedback!
  4. The extension is not focused on test code generation (yet). The intent for v1 was to focus on the generation of the project, references and introduce configuration of code generation. The generated test stubs are intentionally trivial. For vNext there are discussions around the use of T4 templates and/or exposing an extensibility point to enable developers to manage the stub generation themselves.

What’s Next?

Good question … what would you like to see next?

Comments (11)
  1. Great to see you're supporting women who've lost husbands ("Widows Service") – probably should consider supporting Widowers too 🙂

  2. Guess you found another gremlin 🙂

  3. Mike says:

    Just fired up the extension, looks like a great start.  Where can I find the source code so I can contribute?  I'd really like to see the settings be stored ('dont ask me' doesn't fill me with confidence when each time it asks me it has forgotten what I entered last time), and without access to the code, can't really help 🙁

  4. Ahmed Gamal says:

    Good to have support for Private, Protected and Internal Methods.


  5. Joshua Barker says:

    In addition to public methods, it would be nice to have all mockable dependencies created as private members.

    Also, I would like to see Initialize() / Cleanup() stub methods created, and if possible, identify a mocking framework and have all dependencies auto-initialize with mocks or stubs.

    Finally, it would be nice if test methods could be auto-generated wherever a dependency interaction exists.



    namespace Hello.World


       public class Foo


           private IBarService _barService;

           public Foo(IBarService barService) { _barService = barService; }

           public void DoSomething()






    would result in something like:

    namespace Hello.World.Tests



       public class FooTest


               private Foo _foo;

               private IBarService _barService;


       public void InitializeTests()


                    _barService = MockingFramework.Create<IBarService>();

                    _foo = new Foo(_barService);



               public void DoSomething_Should_Call_Blah_On_BarService()






  6. Trent Whiteley says:

    I've installed the Unit Test Generator and restarted VS 2013, but I'm still not seeing the context menu to Generate Unit Tests.  Any idea what I've got wrong?  The Configurat option is available under the Test menu.

  7. @Trent, is focus on a "public" class and method? Can you share a snippet of sample code?

  8. Trent Whiteley says:

    That was the issue.  Thanks!

  9. CAD bloke says:

    Add me to the increasingly massive list of people to ignore who are asking to test non-public methods. It would be nice to not have to find-replace everything with "public" just to work around your dogma.

  10. Leroy says:

    Thank you, this is a real time saver and much appreciated!

  11. Vadim says:

    I just installed Unit Test Generator and tried to use it with NUNIT framework on a Console type application.  I have Console.WriteLine as first statements in every test method but I don't see their output in the output window.  Obviously, either tests fail at initialization or don't run.  When I run Tests->Debug there is information on loaded assemblies and that's all.  I'd like to see detailed diagnostics like "test initialized", "starting test xxx", etc.

    BTW, why .vshost.exe is loaded vs just .exe?

    A second issue (which is likely another "Gremlin"): how do you deal with the EXE (being tested) app.config file?  I don't see it's being copied to the bin/debug for the tests project.

    OK, I copied my app.config file into test project and rebuilt.  There is a connection string which refers to localDB with |DataDirectory| as a part of the path. Do you handle this by any chance? – something tells me that you don't.

Comments are closed.

Skip to main content