In my last post, I explored xunit as an alternative to MSpec. In this blog post, I’m going to do the same with NUnit. Most people underestimate the power of NUnit. It is a great testing framework that has been around since the early days of .NET and Open Source and is still actively maintained. When it comes to tool integration, NUnit has one major advantage: The Resharper plugin is developed by JetBrains and shipped together with every Resharper release. So everybody which uses NUnit never has to worry about if there will be a Resharper integration. Furthermore, they’ll never worry about the plugin no longer being maintained (like in other One-Man-Show-Plugins). In fact there is even a 3.0 Beta release currently available of NUnit, all development is done on Github. Be sure to check out the release notes! Yes, yes nitpickers, it uses attributes and such but who cares?
So to reimplement the basic functionality of Machine.Specifications you need Continue reading
In my last post, I showed how a Heisenbug can look like to you. In this post, I want to explore the different options I was considering to get rid of some of the pesky things around Machine.Specifications. During the work, I did for Machine.Specifications I asked myself more and more if it is really worth maintaining a whole ecosystem of tools when there are excellent frameworks available in the Open Source world. Why did I even look at alternatives? Why didn’t I just say, that’s it and move away from Machine.Specifications? Continue reading
In my last post, I talked about me moving away from maintaining Machine.Specifications. Today I want to give you more insights into the decision process and what else I tried to save the project. When I was working for bbv Software Services AG, I was heavily using MSpec in multiple projects. I and also others in the company liked the lightweight syntax and the code-centric approach to specifications by example. We used it so much that it became together with SpecFlow one of our strategic open source library for specifications. We used SpecFlow in projects where the product owner or business analysts took the time to learn and write Gherkin. We used MSpec when the development team was writing the specifications (of course as closely as possible with the business). Continue reading
Thanks to Matt Ellis and some bug hunting of me I can proudly say that we have released Resharper 9 integration for Machine.Specifications. You can now install the plugin by using the provided extension manager in Resharper 9.
For those who are using Resharper versions older than 9 I pushed an update for the plugin for Resharper 8.2. It resolves an issues when you switch from Debug to Release mode or vice versa while having a unit test session open. If you did, you actually had to restart Visual Studio so that the Resharper plugin picked up the correct output path location of the specs assembly. Older Resharper versions are no longer supported as well as the installation via batch files. If you find anyting feel free to open issues on the github repository.
This is a really quick announcement. I recently released Machine.Specifications 0.9.0. With that release I introduced a breaking change: I disabled the console output capturing by accident. If you are using console outputs in your specs and need to see them then I strongly advise you to upgrade to Machine.Specifications 0.9.1. You only need to upgrade the Machine.Specifications nuget package in your solution. None of the other components are affected. This is the beauty of the new architecture 😉
Have fun and sorry for the inconvenience!
Today we released the next version of Machine.Specifications. This release implements an important feature to move on in the future. We implemented a complete runner dependency abstraction. What does that mean? Let me take a step back.
The picture above shows the state of Machine.Specifications previous to V0.9.0. The console runner, the resharper runner, the TDnet runner and more were directly dependent upon the same Machine.Specifications version. This means when we release a new version of MSpec you actually had to use also the new version of the ReSharper, Console runner and more. This was not only for you as a user cumbersome it was also for us as the maintainers of the library. We had a massive repository with everything in it and released all as a “big chunk”. That made working, forking and all other git operations heavyweight because the repository was quite large. Continue reading
This might seem like a minor release but I personally think is a very good and worthwhile update! The first cool thing in this release is that we have now full AppVeyor support in the console runner. By default the console runner uses auto detection to determine whether it is running under AppVeyor and automatically prints out the necessary outputs for AppVeyor to report the progress, the passed and failed specs and more on the user interface. The auto detection feature uses the APPVEYOR_API_URL environment variable. The auto detection can be disabled by providing the –no-appveyor-autodetect flag to the console runner. This behavior is congruent to the TeamCity integration.
The next very cool and anticipated feature is the resharper gallery integration for the plugin. The Machine.Specification plugin can now be installed by using the Resharper Extension Manager for Resharper 8.0/8.1/8.2 and dotCover 2.6/2.7. The old installation way with batch files is still supported. But I strongly recommend to use the Extension Gallery! You’ll see why at the end of this post.
Before you install the plugin you need to make sure all previously installed MSpec plugins are removed.
By default the batch files installed the plugin files into %APPDATA%\JetBrains\ReSharper\v8.2\Plugins\mspec.
- Make sure you close all instances of VisualStudio and delete the mspec plugin folder.
- After that restart VisualStudio, goto the Resharper > ExtensionManager menu and search for Machine.Specifications.Runner.Resharper.
- Install the latest stable version and you are ready to go!
In the future all plugin updates will be delivered automatically via the Extension Gallery and the old installation procedure with batch files will be deprecated. The final picture says more than thousand words 😉
Last but not least I want to give a shout out to the following contributors who provided the AppVeyor support:
Happy mspecing 😉
After some short nights we finally managed to stabilize the resharper plugin for Machine.Specifications. The latest stable release is 0.8.2. What has changed?
- Fixes specs not being loaded into Resharper
- Fixes specs only temporarily shown when base class has tags attribute
- Support subject attribute on derived and base class in Resharper Runner
Thanks for the patience! Happy coding
I just released the newest stable release of Machine.Specifications. The newest stable release contains the version number 0.8.0. What has changed in this release?
- Resharper 8.2 support
- dotCover 2.7 support
- dotCover 2.0 to 2.2 support dropped
- Resharper 6.0 to 7.0 support dropped
I decided to drop the support for the old versions of dotCover and Resharper. In the future I will only support two versions of Resharper back. Because there is an issue regarding thread appartments with the Resharper 8 Mspec plugin the Resharper 7.1 Mspec plugin is still supported.
If you have any issues please use the official issue tracker.
I just released the newest stable release of Machine.Specifications. The newest stable release contains the version number 0.7.0. What has changed in this release? There is one big change and in fact this is the only relevant change for the users of the library:
- The should extensions have been decoupled into its own nuget package!
Machine.Specifications used to ship directly with its own ShouldExtensions. This was a bit of a pain for people using other assertion libraries like FluentAssertions. I personally prefer also FluentAssertions over other assertion libraries and even over the Machine.Specifications ShouldExtensions. In the past the internally shipped ShouldExtensions would “pollute” IntelliSense for example if you use FluentAssertions. This is now resolved!
The following nuget packages are now available:
Read the following instruction carefully!
If you are a user of the Machine.Specifications ShouldExtensions then upgrade by installing the Machine.Specifications.Should or -Signed package. This has a dependency to Machine.Specifications. I’ve seen issues with nuget that installs a pretty old version especially with the signed package. This seems to be a nuget bug. If this happens just upgrade the Machine.Specifications package in Visual Studio manually afterwards.
If you are a user of for example FluentAssertions then just upgrade the Machine.Specifications or -Signed package and you’ll never see the extension in IntelliSense again (unless you install the package 😉 ).
If you have any issues please use the official github issue tracker.