As I mentioned in my previous post I want to use VIM instead of Visual Studio to work on my logcmd project. This would be a kind of an experiment, but I do have some fair reasons behind that decision. Why do I think VIM is a good alternative to Visual Studio?
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:
2. Get NUnit (in version referenced by NSpec):
install-package nunit -Version 220.127.116.1113
3. Go to DebuggerShim.cs file and change it to look like that:
And that’s it! You can go back to your specs and be delighted by the “unit test” icon beside your spec class.
…and test runner:
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: https://github.com/chrisseroka/Blog.NSpec.Debugging
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
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).
Let’s imagine that we are doing a web application supporting front-end developers. Among all the functionalities we have a simple reusable module to recalculate color values: RGB/HEX.
Separation of Concerns is one of the most important things while doing TDD, that’s why I chose “KnockoutJS” as the framework connecting our view with the logic. Architecture of such application is very simple. At the moment we don’t even have any “back-end” code, but still can do TDD.
The first test
Let’s pick out the ColorCalculator as the target. This is a “class” that is responsible for calculating color values between RGB and HEX.
Immediately after closing the test() function resharper will add “Run test” button on the left. In case of QUnit Resharper will run the test in the default browser using QUnit default template, showing the result as it is:
Test result is also shown normally in ReSharper “Unit Test Sessions” window.
Extracting test project
First add a new project to the current solution. The project type should be “Empty Web Application” (in contrary to normal unit test project when we add “Class library”). Then you can add your test files to the project. You also need to reference the tested code. To do it, add existing script files as “links”:
This is the drawback of our solution. Whole reference tree needs to be reproduced . But it’s not that bad, we don’t change the reference tree that often but instead we have all the code in one place and it’s checked during the build time. Complete test solution should look like that:
Next you need to do a little trick to copy referenced files to the solution. To do it “Edit project file” and add the following code to the end of the test project:
I hope in the next releases of Visual Studio such behaviour will be applied automatically.
Finally modify a little the test code adding a reference to the code under testing (/// expression):
And that’s it! – after adding some tests and implementing the functionality correctly you can right click the solution, click “Run all tests” and be sure that everything is correct!
Debugging the tests
Wiseman said: “If you need to debug unit test then something is wrong with it’s unitness.”
Switching to PhantomJS
You need to specify the path to PhantomJS that can be downloaded from here.
Download and play
You can download the whole solution here: FrontEndTools.zip
There’s still a lot to do – you can add tests to the ColorBoxViewModel and test “toRgb” function that is far more interesting.