Programming (back-end)

Debugging NSpec with VisualStudio/Resharper – simple trick

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

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).


  • 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


  • 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:

Programming (back-end)

Improve your testing experience with NSpec, best BDD test framework

Amongst long list of benefits that automated testing gives our projects we have ‘documentation’ feature. I think it takes even one of the first places. Many times I was looking at unit tests trying to decipher what they did and why they were there. Ask yourself a question if your unit test project is a mixture of test methods or it shapes a specification that you can share with your client. Saying ‘specification’ I meant something like that:


This is a test result generated by NSpec for a sample project. NSpec is a beautiful test framework that I’ve focused on for the last several months and probably will stay for a longer time.

If you really want to change your testing experience it’s more often about the approach not a framework. I hate when people see a goal in moving from NUnit to xUnit because it’s almost only changing attributes used for testing. NSpec also allows you to omit class/method attributes but the key concept is to create scenarios that are cool to maintain. For me the testing experience is close to Jasmine (JavaScript) but here we can use lambdas instead of long “function(){}” syntax. The image is worth a thousand words so:


It generates the following result:


Why better than: MSTest/NUnit/xUnit

These are just TDD frameworks with flat structure. No way to define scenarios. NSpec enables you to build real scenarios. It also simplifies the way we organise tests (far easier to add new test, find the proper place). Contexts decrease the size of Arrange/Given part.

Why better than MSpec:

Both are BDD frameworks, but NSpec has more user-friendly syntaxt. It’s possible to avoid hard string concatenation (like ShouldDoSomething, or should_do_something_else). Test result for complex scenarios looks better, you can have more levels. MSpec also takes advantage of lambdas. If you don’t like it, with NSpec you can write tests without them (using conventions).

Why better than SpecFlow:

I don’t believe that the client can develop SpecFlow*.feature files. Because of that I don’t like the workload involved with maintaining *.feature files and their mappings. I’m a developer and what I really want to do is to write code. Although what’s good in SpecFlow is creating specification-by-example.

NSpec disadvantages:

* debugging – see this official tutorial or install additional test adapter
* no resharper support – still in progress
* lot of lambdas (non-mandatory) – for some people it’s an advantage but maybe not for all

Regarding debugging with resharper I have my own solution.Check this out here

Keep in touch.

Programming (back-end)

.NET types can have spaces. And not only spaces.

No, you cannot write code like that:


At the same time there is no new C# 9.0 nor C# One that allow to write such code. But there is a namespace called System.Reflection.Emit containing TypeBuilder that can generate valid CLR types. Here’s a sample code that you can use, to put some more life into your Employee entity:

I don’t suggest to start writing code like that, but have it in mind while playing with reflection on some external libraries (I guess there would be a problem when serializing such object to XML).