TagTest Driven Development

Code Quality! Building code you won’t curse tomorrow.


These are the slides and comments of a presentation I held for bbv Software services AG. The presentation is about how we get quality into our code. Buzzwords: Fokus, frequent measurements, strong team, clean code, pair programming, test driven development, acceptance tests, continuous integration, collective code ownership, team learning. Urs Enzler Senior Software Architect bbv Software Services AG urs.enzler _at_ bbv.ch  (replace _at_ with @) www.bbv.ch Copyright © 2010 bbv Software Services...

Mocking Kata – Copier (.NET)


To continue my series on Mocking Katas (see Mocking Kata – Instrument Processor for the last Kata), I’ll show you a very simple Kata that I normally use in my Test Driven Development training courses to introduce mocks (created manually or dynamically with the use of a mocking framework): the CharacterCopier.

Mocking Kata – Instrument Processor (.NET)


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 ). 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...

Agile UI Development in .NET: Tools


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

How to find a concurrency bug with java?


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

Passive View Command (PVC) Pattern


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.

The Essence of Scrum And Test Driven Development


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: Focus 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: Focus Feedback After that, I asked myself: “Are there other things I like with these root causes?”. Yes there are: Playing Volleyball and...

Test Driven Development Speech at SET 2009


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…

Test Driven Development Myths


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

Recent Posts