Home / Archive by category "Test Driven Development"

Machine.Specifications – The alternative nunit

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

Machine.Specifications – The alternative xunit

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

OMG! They Killed My Stacktrace!

I can’t get that flashing red light on my desktop out of my mind. It’s nagging me. What is it? Oh my… I just killed the build! How embarrassing — only a few weeks on the team and I’m already a trouble-maker. Resistance is futile. The flashing red light got me. Five acceptance tests are failing on the build server. Hold on — those tests are working on my machine! Can’t I just add a works on my machine badge and carry on with the other things I have in the work pipeline? The “getting things done guy” inside me says yes, but my engineer heart tells me no. I roll up my sleeves and start analyzing what went wrong.

If you want to know how this story goes on, I suggest you read the full blog post originally posted on the particular blog.

Machine.Specifications.Runner.Resharper 1.0.0 released

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.

2014_12_29_21_31_59_JetBRAINS_.NET_Tools_Extensions

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.

 

Clean Code: Test data preparation or what test data builders are good for

Today I read this blog post about how to simplify test data preparation.

The author of the blog post states that setting up test data for tests is sometimes difficult and bloats up the test code, resulting in bad readability and maintainability. I completely agree with that.

The author continues by solving this problem by loading the test data from a file and using it in the test. That minimizes the code needed to set-up the test data, but results in a disconnect between the test and the data or example used for it. Leaving us with an obscure unit test.

We solve this problem differently.

Continue reading

Machine.Specifications 0.9.1 released

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!

Clean Code Cheat Sheet (V 2.4)

I updated my clean code cheat sheet.

This time there are just minor changes:

  • Principles: mind-sized components
  • Class Design: do stuff or know others, but not both
  • Maintainability killers: tangles
  • Refactoring patterns: refactor before adding functionality, small refactorings
  • removed duplication regarding one test asserts one thing
  • TDD principles: Test domain specific languages
  • fixed a bug in the ATDD/TDD cycle (run all acceptance tests)

If you miss something or think that there is something just plain wrong, please write a comment below.

Link: Clean Code V2.4

CleanCodeCheatSheet

Machine.Specifications 0.9.0 released

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.

DependenciesOldWay

 

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