Monthly Archives: May 2016

NUnit 3 and the GUI Runner

development, tests, visual-studio

NUnit has been my favorite unit test framework for years.  I find it has the features that work best for me.

I recently upgraded to NUnit 3.2.  The latest version of NUnit can be downloaded from here.

NUnit GUI Runner
NUnit GUI Runner

NUnit has always had several methods to run the tests you write.  Probably the most popular way to run the tests, at least as a developer in the middle of working on a particular feature, has been the GUI runner.  It provides a quick visual mechanism of seeing which of your tests have failed and the reasons why.  After installing NUnit 3.2 I went looking for the GUI Runner but couldn’t find it.  After a bit more digging I found a post by the developers indicating that they had split the GUI runner development from the framework development and that the GUI was still months away from completion.

In short, the “official” way to run unit tests now in NUnit 3 is to use various test runners.  Until the GUI Runner makes a comeback, we’re going to configure Visual Studio’s test runner to run our tests.  It’s pretty easy.

Test Explorer
Test Explorer

Open Visual Studio (I’m not going to go into how to use NUnit in this post. NUnit has some really great and easy to follow documentation.)  No need to open or create a project.  Click on the Tools menu, then Extensions and Updates.  Select “Online” then in the search bar type “NUnit Test Adapter”.  Make sure you pick the NUnit3 Test Adapter.  Click on it then install.  You will likely be asked to restart Visual Studio.

Now when you run your test project you can open the Test Explorer (Test Menu, Windows, Test Explorer).  If you haven’t built your test project lately do so now.  Once you’ve built your test project you will see all of your tests listed in the Test Explorer.  With the “Group By” drop down in the upper left corner of the Test Explorer window you can change how your tests are grouped.  Setting it to “Class” will group your tests similarly to the default grouping in the NUnit GUI Runner, grouping them by the class the tests are contained in.  You can also right-click in the Test Explorer window to change the grouping option.

You will notice that the tests are not grouped like they are in the NUnit GUI Runner.  There are ways of doing it in Visual Studio Test Explorer, but I won’t cover that here.  Without the grouping it can be a bit difficult to run a subset of your tests, useful if you are working on a particular feature and just want to run the tests applicable to that feature.  A nice feature of the Visual Studio Test integration that partially solves this problem is the ability to run your tests by scope.  You can right click within a function, within a class our outside of a class.  This will provide the option to “Run Tests” in the context menu.  Clicking this will run all tests in the clicked scope.  It will run the single test function, all tests in the selected class or all tests in the namespace, respectively.

Test Icons
Test Icons

Another nice feature of the test runner is the visual cues on your tests.  In the image to the right you can see the 3 versions of the icons representing an un-run test, a successful test and a failed test.  Clicking on any of the icons lets you run the test directly and even debug the code without starting the whole project.

UPDATE: There has been some progress on the GUI Runner though you have to download the code and run it yourself if you want to use it.  It is on the NUnit Github site here.

Debugging a WCF Service

development, wcf

WCF Services can be a pain to debug.  By default they do not propagate error and exception information to the caller for security reasons.

There are several different approaches you can take to debug your WCF service, but let’s take a look at one of the most powerful ones.

You can enable a trace log for your service very easily by adding the following to your app/web config file:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Information, ActivityTracing"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

You can use a relative path or leave the path out completely in which case the log will be written to the current directory.  This will depend on how your hosting your service.  For this reason it is often easier to just specify a full path.

Now when you run your application you will see a file created.  If you double click on the file, or otherwise launch SvcTraceViewer.exe you will get lots of good information about your service.

If you are getting an exception, the trace should have some entries highlighted in red.  Examining those entries more closely will provide details on the underlying exception.  In my example below we see that I have a serialization error (the exception items are selected so they are not showing as red in the screenshot):

The WCF tracing is built on top of System.Diagnostics.  WCF is not the only system that provides trace information.  Trace Logging is highly configurable.  You can set different log levels for different types of information.  You can set different targets.  You can consume traces in different ways as well.

This MSDN article provides a good starting point for customizing your trace logging.

The most common setting you will likely use though is the Trace Level.  This will let you make the log extremely verbose if trying to track down a difficult bug or performance issue, or you can set the log to a higher level so the log doesn’t grow so large but you still get critical errors.

Some common settings would be as follows:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Off"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>
<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Information, ActivityTracing"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

This MSDN article covers recommended settings for production systems:

<system.diagnostics>
    <sources>
        <source name="System.ServiceModel"
                switchValue="Warning"
                propagateActivity="true">
            <listeners>
                <add name="traceListener"
                     type="System.Diagnostics.XmlWriterTraceListener"
                     initializeData="C:\Logs\Traces.svclog"  />
            </listeners>
        </source>
    </sources>
</system.diagnostics>

You can also use the Configuration Editor Tool to edit your config file, enable tracing and setting the trace level.

Now off to fix the error.