On our journey from C# to F#, we were at a point where we changed our (unit) testing strategy. Our approach just didn’t feel right anymore. We struggled to do TDD because we didn’t get the tests to fail first. We wrote tests that didn’t increase our confidence and started thinking of them as waste.
This post is part of the F# Advent Calendar 2021
Thanks to Sergey Tihon for organising the Advent Calendar.
I’m a big fan of R# and xBehave.net. So it was time to mix them up.
I can now write "my step".Step and press Tab and what I get is "my step"._(() => );.
Woohoo!
Here is how you can use a R# source template to create xBehave.net steps.
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...
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...
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...
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...
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...
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...
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...