NSpec is purely awesome, although coming with little painful disadvantage – debugging. The default approach (DebuggerShim.cs) is weak because forces me to always navigate to a separate file and change some code. Authors of this great library claim in the documentation that they already work on “fully integrated support”, but it’s not there yet. Fortunately you can apply one simple trick to make it work far better.

1. Get Nspec: install-package nspec

2. Get NUnit (in version referenced by NSpec): install-package nunit -Version 2.5.7.10213

3. Go to DebuggerShim.cs file and change it to look like that:

nspec - DebuggerShim.cs

And that’s it! You can go back to your specs and be delighted by the “unit test” icon beside your spec class.

NSpec - test result

…and test runner:

NSpec - Run spec

What has happened?

DebuggerShim was a tool (nunit TestFixture) that run some given specification. By renaming it to “nspec” class it’s become a wrapper for all specifications. For NSpec it doesn’t matter because it doesn’t care about NUnit attributes nor abstract classes. If it’s in the same namespace as other specifications, then we do not have to change anything and Resharper starts to detect it as NUnit test fixture (as it derives from our custom “nspec” test fixture).

Advantages:

  • Simple – no need to install any plugin/adapter
  • Unobtrusive – no need to change existing specifications
  • Easy to update – if NSpec gets fully integrated debugging support, then just delete custom abstract nspec wrapper
  • Additionaly as a test output we see specification generated by NSpec runner

Disadvantages:

  • It runs the whole specification, it’s not possible to debug single context. This is particularly painful in case of big (and slow) UI testing scenarios. In that case I try to split them into several more specific scenarios.

You can download the test sample here: https://github.com/chrisseroka/Blog.NSpec.Debugging

Advertisements

2 thoughts on “Debugging NSpec with VisualStudio/Resharper – simple trick

    1. I see you complained on C# naming, but that’s the convention in testing (especially in NSpec). This way the class names are transformed easily to output scenarios.
      There’s no rule without exceptions.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s