So as we have come along the path our sublime instance is starting to feel quite a bit more customized than it was before. We can now build, have git/github integration, and of course have awesome command line integration but what about running tests?
We will start with the simplest way of running tests. This may not work for all of your scenarios and does somewhat require you to have thought about things in advance.
If you for instance started off from the beginning with resharper as a test runner you are probably have a test suite that will be difficult to use. Likely it is all in one assembly regardless of whether its a unit test or an integration test. Quite likely the tests have large numbers of dependencies. And to be frank your unit tests probably don’t run properly in linux anyways. Yeah this kind of sucks but can be fixed.
To start with there is no integrated right click->debug test in sublime. I find however that this is not something I missed. Maybe its having worked for a few years building embedded systems where there was no debugger (except dumping as hex pieces of memory).
Let’s talk about the simplest way to run tests from sublime and the general workflow. Normally when working with sublime I have multiple test suites either separated by category or by assembly. I have unit tests which are quick to run and then all other tests. I rarely if ever run the other tests locally. Instead I let a CI server run those. My unit tests should be run in and this would give you a new buffer with the output of your tests running. For a huge portion of code you will be working on this is *good enough*. If you have a 10 second cycle on tests running it is completely reasonable. eg
ctrl+shift+c run >
where I have a script called run that runs nunit in the way I want.
There are however some other things you can do if you want to be more fancy. The first is you could assign the running of the script to a key in sublime. This is actually quite easy any command can be assigned to any key by editing your keymap http://sublimetext.info/docs/en/reference/key_bindings.html
Another cool option that is quite easy to enable to get a notification from linux on the status of your build/test run. This can be done trivial using notify-send in your small script above based on return values from processes.
notify-send ‘Hello world!’ ‘This is an example notification.’ –icon=dialog-information
You can even change the icons to say red/green circles for the notification.
Now if your tests are more than 10 seconds. The first strategy would be to start putting them into categories that make sense to you. This way you can only run tests within a given category. This step alone will normally be good enough to get your test runs back under 10 seconds (I prefer 1-2 seconds). If this is not then perhaps your code base has become too dependent on the tool (15 categories 10 seconds each…). One thing you will notice is that your tests in general will run far faster than through tools like VS/R# when being run from the command line.
OK so now we have basic unit test integration. There are still a lot of problems with .NET code. In the next post we will look at what some of these are and how to deal with them.