The first post - About the blog

Abstract:

• Hello!
• Every post in this blog will have an abstract like this to make stuff quickly graspable for people googling.
• This blog is mainly about TDD, which I love. It is also about .NET and architecture.
• The target audience is people new to TDD, as well as experienced practitioners interested in software architecture.

Hi there internet wanderer and welcome to my blog!

Since this is the first post here comes the mandatory introductory snippet, setting the tone for the posts that will follow.

What's it about?

As you may have guessed from the title, TDD will play a central part in the musings of this blog. OMG and WTF will play a lesser part, sticking to the background. :)

Test Driven Development is a big passion of mine, and in my work as a web developer I have practiced it daily for a long time, tackling obstacles with it, leaned on it, built both great and foolish things in its name, and felt the benefits of it through its presence and absence in various projects.

In this blog I will talk about the problems and solutions related to TTD I'm currently obsessing about, hopefully sparking discussion from other practitioners who've been there, and sparking ideas and questions in developers who haven't.

TDD is not something that lives in isolation however, and this blog will also be about software architecture, new technologies on the .NET platform and other interesting things. 

Who is the blog for?

TDD has become quite a fashionable doctrine to subscribe to in the past couple of years. For many organisations it is an integral part of the development process, and most books from learned men takes the presence of a test suite for granted. Something to lean on for refactoring, measure the code coverage of and use as a measure of the quality of the code.

For many developers however, TDD is a buzzword, and writing unit tests is something they've heard they ought to be doing, but not something that's done in practise. Indeed, if you're not writing any unit tests, how do you begin? Most projects where unit testing is absent does not have an architecture that lends itself well to start writing tests, so how are the developers in the project supposed to learn unit testing even if they want to? Unit testing in such projects often requires you to break existing dependencies, something that is hard to do at the best of times.

The only real way to learn something is through practice. This blog aims to give practical examples of common ways to write Unit Tests, targeted at people with limited experience. I will try to provide examples of the basics, and show what you need to do to start incorporating tests into both your existing and new projects.

For Test Driven people who are already flying, this blog aims to provide interesting material on architecture and ways to make your life and coding easier and more elegant. We'll see how that goes. :)