Machine.Specifications for ReSharper 6 now available

Hadi Hariri — Wed, 20 Jul 2011 14:16:00 GMT

Many, myself included, have been eagerly awaiting the release of the ReSharper Runner of Machine.Specification (MSpec) for ReSharper 6. I’m glad to announce that this is now available, which is the result of a team-effort between Victor Kropp, Chris Nicola, myself and of course Alexander Gross, long-time contributor and main maintainer of the MSpec project.

NuGet packages have already been updated to support ReSharper 6. The source code can also be obtained via SymbolSource.org if using NuGet or directly from Alexander’s GitHub account.

Installing the Runner in ReSharper 6

If you’re new to MSpec or have simply forgotten how to install the runner under ReSharper, here are some simple steps to use Mspec in your project and integrate it with ReSharper:

1. Run the command install-package Machine.Specifications (or Machine.Specifications-Signed if you want the signed version). If this is an existing project, issue the command update-package instead of install-package.

2. Inside the packages folder corresponding to Machine.Specifications, a tools folder is created with a series of assemblies and some batch files. There are a series of batch files named InstallResharperRunner.X.X. – VS20XX.bat where X’s correspond to the version of ReSharper and of Visual Studio. By executing the corresponding one, it will copy the assemblies to the ReSharper plug-in folder.

You can of course do the second step manually, by copying the Machine.Specifications.ReSharperRunner.X.Y files to the ReSharper Plugins folder, located either under the ReSharper bin folder in %Program Files%\JetBrains\ReSharperX\bin (for all users) or under %APPDATA%\JetBrains\ReSharperX\bin (user-specific settings).

With that you should be up and running.

Enjoy.

Regression tests, do it now.

Hadi Hariri — Mon, 30 Aug 2010 12:24:00 GMT

When you encounter a bug, do you first write a failing test before fixing it? You should. But the vast majority of us sometimes do not. External pressure (read Customer, Teammates or Management) moves us in the opposite direction. Everything we’ve learnt about unit testing and good software practices go out the window, and the sheer pressure forces us to fix the issue as fast as possible! We focus more on getting the job done* and deploying than worrying about adding another test to our suite.

Adding that test is not about increasing our code coverage or patting ourselves on the back, with an optional tweet, that we are good developers. It’s about putting regression tests in place.

Of course, we could always just apply the fix, and then later, calmly add a test. However, there’s always another urgent bug fix, feature, or customer breathing down our necks, so things just get putt off.

It’s hard to not be tempted to just fix something then and there. Fight the temptation though if you can. Write that failing test first!

[*Implicitly changing the definition of Done on the go]

Hadi Hariri : Testing

Machine.Specifications for ReSharper 6 now available

Regression tests, do it now.