Home / Posts tagged "TDD"

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


Legacy Code and Now What?

cross-post from http://blog.bbv.ch/2013/06/10/legacy-code-and-now-what/



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 understood, analyzed and put into context with the feature you are implementing. You start drawing a sequence diagram of what is going on in that code but the more you dive into it the more confusing it gets. The motivation decreases, frustration chimes in. Maybe someone in your team can help you understand the code. You call your colleague, who immediately sits down with you trying to help understanding. Minutes later your friend has no clue either and tells you to “just freaking hack it into the code”. Despite feeling a bit dirty you have no other chance than to hack it. The feature has to be completed better yesterday than tomorrow! But you are a hero, aren’t you?! You can do it! The motivation comes back and finally you get the task done and the feature you are working on is ready to be demonstrated during the sprint review.

The sprint review starts, your product owner and your team members are gathered around the demo computer. You are first to show your new feature to the product owner. The feature works and fully impresses your product owner. Now, it’s your team mate’s turn to present the feature he has been working on. He starts presenting, but suddenly… BOOOM… the application crashes. Your colleague almost freaks out because he wanted to receive a pat on the back from the product owner, too. He blames you for killing his feature. The product owner gets angry and suddenly starts complaining about your team making more mistakes than pushing out new features. Your team mate finally says what your team always had in mind: He demands a rewrite of the whole software because you have reached a state where you cannot add any new features without severely damaging old ones. But guess what! Your product owner demands more features nonetheless. And he wants them now!

Do you recognize the situation? Let us analyze what happened here.

Continue reading

Clean Code Cheat Sheet

There is an updated version at http://www.planetgeek.ch/2014/11/18/clean-code-cheat-sheet-v-2-4/

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 Code V2.2

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License.

Feedback is highly welcome. Please write a comment below.

Clean Code Cheat Sheet Teaser

Update V 2.1: thanks for your feedback

  • added + and – for DOs and DONTs to make it easier to tell them apart
  • added a creative commons Attribution 3.0 Unported license.

Update V 2.2:

  • changed the colours to be better distinguishable

The fluent calculator kata – Rev 2

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 up with.

Continue reading

FakeItEasy and Windows Store Apps are becoming friends

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.
Continue reading

How to suppress exceptions with fluent assertions

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:

public class SomeComponent
   public void Do() {
      ITransaction tx = this.session.BeginTransaction();
      try {
      } catch(DataException e) {

Now how would you write the requirements above in two separate unit tests? Here comes FluentAssertions into the play.

Continue reading

Create your own hamcrest matcher

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” and “getNumber” and you would like to check whether the resulting object
has the correct values.
In my opinion the best way to verify this is to create two matchers and
combine them. Before we can combine these two matchers let’s see how to
create them. Continue reading

Structure your code by feature

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.

Continue reading

Different Flavours of Pair Programming

Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.

Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.

To get most out of pair programming, you first have to know your setup.

Continue reading