Preface

When I started out with unit testing in 2007, I made every imaginable mistake there is. I didn't understand how to isolate my tests from database calls. I didn't understand how to structure my tests. I had no idea what constituted a good test and what should be tested. It was a train wreck, and even if my test suite was pretty much useless, I still found I had gained a lot of knowledge of the system while trying to test it. So, for the next project, I gave it another go.

Once again, in my second project, I failed at writing unit tests. They where brittle, unmaintainable, and quite useless as they would only run under conditions that where reproducible solely on my developer machine. But even if the test suite was crap, the project itself was a success and the code produced was considered to be of very high-quality.

So, I went at it again and again and again, every time coming up with a slightly better end result, until I got to a point where the test suite was a major deliverable of the project, and an enabler for maintenance. However, it took me a long time to get there.

I had been teaching and preaching test-driven development for years, until I began to notice that people around me were doing it, too. I no longer had to justify TDD to people around me, and testing would now be a natural part of any project, and not just something I did on the side. This was splendid, indeed! Mission accomplished!

In 2009, I found out about the F# language from Microsoft Research, and it got my attention. I decided to learn it, and started to hack away during my evenings and weekends to get to the bottom of functional programming. After a while, I felt sure enough to start bringing it into clients' projects. I began with only small snippets at the start, but after a while, the snippets got bigger and bigger, and before anyone knew what was going on, we were implementing services in F#.

For me, test-driven development has been an enabler for quality. It is what enhances the quality in a given project by setting up requirements on the code. The code needs to expose its inner parts in a manner that can be tested in isolation. This leads to good object-oriented design and separation of concerns.

However, at the same time, I had a few worries that the test suite made too large impact on the system design. Why isn't it that we design systems that are testable by default, and why do we need tests to enforce this design thinking?

Functional programming has truly been an eye-opener for me. There is something funny about object-oriented programming I didn't realize before I invested in F# fully. Why is it that I can't create a class in the system without setting up a dependency injection framework? Why do we have all these classes that are cohesive enough that they only do one thing, but that one thing is so abstract that the name of the class is more confusing than informative? Why does every class in the system have an interface identical to the class implementation?

The answer to these questions is that test-driven development has forced these frameworks and patterns onto object-oriented design in order to work together in harmony, but in reality, you end up with a lot of ceremonial code that does very little.

Functional programming is the answer to this question; anyone care to object?

If we stop thinking about systems as interconnected objects and instead see them as functions passing data around, we make our design so much easier. We can skip the dependency injection framework because we don't need to manage an object dependency graph. We do not need interfaces because we can describe functions by their signature. Instead, we can solely focus on the input and what the desired output will be, and from this, we will derive our tests.

While my colleagues struggle with their cloud in the castle abstractions, I produce code that is short, concise, and completely covered. This is the best way to evangelize something better. We do not need to sell functional programming. It sells itself.

Yet, here I have written a book about producing quality code with functional programming and testing. This is a starting point for anyone who is familiar with object-oriented programming and wants to learn about the alternatives that may bring about a more qualitative life as a professional programmer.

I wanted to write this book in order to spread the word and show my peers what huge value they're missing out on by trying to produce value with C# and object orientation alone. My intention is to express the lost love I have found for programming after being stuck in large enterprise code bases where every change would have a ripple of side effects. I want to put this book in the hand of every developer I meet who is asking himself, "How could I do better?"

Your managers will love you for writing less code and getting done at a much faster rate of speed. Your clients will love you for producing code with less bugs. And you will love going to work to deliver code with higher value and less ceremonial waste.

Understanding functional programming and test-driven development are the key points in advancing your career and securing your knowledge base for the inevitable future.