Slow tests, courage and zombie driven development

When I was going over my old posts from January 2009 I had a flashback of how I for a while aimed at posting something every other day. Today I must say quality may have suffered from that and I apologize... So here are the highlights...

Another example on ways to to make your code testable

Before you go crazy on me screaming that making code testable for the sake of testability is bad I'd like to agree. However testable code have other nice properties like loose coupling for example - something you likely want. Anyway, in this article there is a great comparison between using inheritance vs composition to implement a class and how that affects both the design of the class and the tests. TL/DR; use composition and dependency injection. Please.

The 2008 advent calendar - 24 ways to write a test

Oh yes I love December 2008. I decided to challenge myself and write the same test in 24 different ways. And it was an interesting experience!

Go for C# developers: Unit testing

Let’s talk about unit testing and Go. The fact that unit tests typically are placed side by side with the code (in the same package as the code under test) and how Go deals with exposing functions outside of a package leads to some interesting things.

DRY vs WET

I've always been and advocate for intentionally ignoring the DRY (Don't Repeat Yourself) rule when writing tests if it makes the tests easier to understand. I've even (repeatably) said that some duplication might actually be a good thing when writing tests.

Code Coverage and nothing is too simple to test

So time to look back again and update some old opinions from June 2008. And while there are some other useful stuff in there I'll focus on code coverage and testing simple things. Because I feel the urge to explain myself...

Books, Mocks and Open Source

So time to look back again and update some old opinions from May 2008. This time I'd like to talk about three old articles.

Don't hold me accountable for old opinions

Once in a while I get a comment about something I wrote a long time ago and sometimes that is embarrassing as the opinion I expressed a while back might not be how I feel today on that subject. Hence I decided to look into some old blog posts and see how bad it is...

Thinking for Programmers

I was watching this great recording from last year on how programmers should think. It talks a lot about the importance of writing a specification for your code.

Never hide a TUF in a TUC

This slogan (never hide a TUF in a TUC) was introduced (to me at least) in 2010 by Michael Feathers. Turns out it is a pretty good tool to explain and steer people in the right direction when they are new to writing unit tests. But what is TUF and TUC?

Testing with fakes or stubs? That is the question!

I like testing with stubs. But once in a while I encounter people that rather use fakes. And that is a pattern I try to avoid.

Spies and Stubs

I was reading this article which is a response to an email from a person liking mocks but disliking spies. Before starting to read I was confused since I personally dislike mocks and spies sounded even worse. However it turned out I was wrong.

What is your test ROI

When we write code we sometimes get carried away and forget to think about if we are spending our time right. However more common I see people (including myself) forgetting to think of cost vs benefit of the tests we write.

TDD helps you enforce the single responsibility principle

When I was writing last week's post I also thought about how TDD (or rather BDD) has helped me to early detect violations of the single responsibility principle.

Will TDD really drive your design?

One of the most common arguments I've heard from TDD skeptics is that TDD does not drive your design. And this statement is both true and false.