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 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...
cross-post from Every day is a ground hog day. It is eight o’clock in the morning. You come into the office, look at the Scrum board of your current project and pick the next task of the user story with the highest priority. You sit fully motivated in front of your computer, open up your favorite IDE and start to implement the task. But wait! Something is wrong! First, you have to fully grasp the code you tend to put the feature into. But there is a lot of code in that area, which needs to be...
There is an updated version at It took me about one and a half year to update my cheat sheet about clean code and TDD. But now, it’s here. The cheat sheet has grown quite a bit and now contains principles, patterns, smells and guidelines for clean code class and package design TDD – Test Driven Development ATDD – Acceptance Test Driven Development Continuous Integration I had to re-layout the sheets because maintenance became a nightmare (yes, very ironic). Download: Clean...
In my last post I described the fluent calculator kata which we came up with for our coding dojo. When we started implementing the kata we decided to modify the initial set of “requirements” slightly in order to make it a bit more complex. Here is the changed requirement: The calculator should never throw exceptions. When an overflow occurs the calculator should throw an InvalidOperationException with an inner ArithmeticException. I’ll show you what design and tests we came...
Probably you already know it: The new Windows Store App class libraries prevent proxy generating using frameworks like Castle.Core because System.Reflection.Emit namespace is missing in the limited framework they’re using.
But we still want to do TDD and therefore we need a nice mocking framework, like FakeItEasy, don’t we?
In this blog post I will show you the best way I came up with to develop Windows Store App compatible code with TDD.
This is the presentation I gave at the .Net System Event by bbv Software Services AG in Lucerne in June 2012:
Imagine you need to code the following requirements:
When an exception is thrown the transaction must be rolled back
The thrown exception must be rethrown
The productive code could look like:
Now how would you write the requirements above in two separate unit tests? Here comes FluentAssertions into the play.
If you are familiar with hamcrest and JUnit the time will come when you have the need to create your own matchers. Creating your own matcher can be as simple as useful. One reason for creating your own matcher could be that your object is not a default object like a String or a Collection. And if you would like to get a more readable version of the assert for the next developer who has to read your test. Let’s make an example. If you have an object with two methods; “getName”...
cross-post from bbv blog
When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.