We use Coding Katas in Coding Dojos to improve our programming skills. This includes skills in software design, refactoring, Test Driven Development, Mocking, tool usage and a lot of other tiny stuff.

However, I found only a few Katas, especially Katas including the need for mocks (see for example http://codingkata.org/). Most Katas are very algorithmic, which is good for learning TDD. But its bad for learning how to use mocks.

Therefore, I started to invent my own Mocking Katas. I use these in my training courses on Test Driven Development.

.NET, Test Driven Development Kata, Mocking, Test Driven Development, unit testing

In the last post, I showed you the big picture of my UI design pattern. Before I can start showing you sample code for the different parts, I need to introduce some tools, which are used to glue all the tiny parts together:

• Dependency Injection
• Design By Contract
• Synchronous and Asynchronous Communication
• Test Driven Development

.NET, Administration, Agile .NET, Agile, Architecture, code contracts, event broker, Ninject, Test Driven Development, User Interface

In my first post (link) I’ve explained what StyleCop is and how you can start with your own StyleCop rules. We will now dig a little bit deeper into the jungle of StyleCop….

.NET, Software, Sourceanalysis .NET, Source Analysis, TDD, Test Driven Development

How to find a concurrency bug – this was the question I asked myself some time ago.
It is always very hard to find a concurrency bug. Mostly you have no idea when it happens or if it is really a concurrency issue or some nasty bit of code. If it is a concurrency issue the question is if the bug is in your code or in a supplied library? Will the problem happen only on multicore processors or on any machine? Besides the technical problem the customer is eager to get a solution and management… we’ll i guess you know the story.
I won’t be able to tell you everything there is to know about concurrency testing – but I’ll show you a way that worked for me in most cases.

Java, Methodology, Testing Concurrency, Java, test, Test Driven Development, Testing

When I’m coaching teams in Test Driven Development (TDD), I’m often asked how to deal with the User Interface (UI). The problem is that the unit test frameworks are weak in testing Forms, Controls, Buttons, Grids, and so on. Weak because they do not support it at all or the tests become very fragile (e.g. renaming a Label causes the test to fail).

We address this problem with the Passive View Command pattern, PVC for short.

.NET, Architecture, Testing Model-View-Controller, Model-View-Presenter, Passive View, Passive View Command, Patterns, PVC, Test Driven Development, Testability, Unit Test

Lately, I asked myself why I like Scrum most. I’m a big fan of Scrum because of a lot of things. So I asked myself: “What is the root cause of all these”.

I tracked it down to two main things:

1. Focus
2. Feedback

I’ll come back to that later.

I’m also a big fan of Test Driven Development. Guess what,  I performed a root cause analysis on TDD, too. And once again:

1. Focus
2. Feedback

After that, I asked myself: “Are there other things I like with these root causes?”.

Yes there are:

• Playing Volleyball and Gaming in general: focus on playing (one round after another), feedback (you win or lose)
• Playing Saxophone: focus on playing (I forget everything else while playing, believe me), feedback (you hear what you play and you either like it or or you try harder)

So it seems, I’m addicted to the Focus-Feedback drug :-O

Methodology, Test Driven Development Feedback, Focus, scrum, TDD, Test Driven Development

For those of you interested in TDD:

I’m speaking at the conference SET (Software Engineering Today) in Schlieren (Zurich) on Tuesday May 5th.

I’ll show the basics of the TDD cycle, benefits and pitfalls, and how you get started.

Link to SET 2009: SET 2009

Link to my session (german): TDD

Looking forward to some interesting discussions…

Methodology Conference, SET, TDD, Test Driven Development, unit testing

I’m often hearing thoughts about Test Driven Development from people not using it, which are not true (at least not 100%).

Therefore, I want to describe some of these myths here:

• Writing unit tests is difficult and complex
• Projects take longer because of the additional test code that has to be written
• Not everything can be tested with unit tests. Therefore TDD cannot be used.
• There is no need for architecture and design because TDD claims to evolve that from tests

Methodology, Software, Test Driven Development Architecture, Design, Myths, TDD, Test Driven Development, Unit Test