cross-post from bbv blog

When software projects grow both in age and size the developers often struggle with the structure of the code. It gets more and more difficult to find the class you have to change for a new requirement. In this post, I’ll show you how we organize our code and how we derive our structure directly from the requirements.

.NET, Agile, Architecture, Clean Code, Methodology, Test Driven Development Agile, Architecture, Clean Code, TDD

Pair programming – two developers working together at a single computer – can result in better software written faster, but only if you know what you do.

Pair programming is not just sitting together and code as you would when being alone. Unfortunately, this is what most developers practice – resulting in a painful and ineffective experience.

To get most out of pair programming, you first have to know your setup.

Agile, Methodology, Test Driven Development Pair Programming, TDD

Do you program or do you already TDD?
If you prefer to do TDD you will love the eclipse plug-in called MoreUnit. It is as simple as powerful. All it does is executing tests from corresponding productive class and makes it very simple to change between them.
Just press Ctrl-J (like Jump) to jump from test to implementing class and the other way. Or press Ctrl-R (like Run) to run the test regardless if you are in the test or the implementation class.

Agile, Java, Test Driven Development Agile, eclipse, Java, Mockito, TDD, Test Driven Development, Testing, Unit Test, unit testing

Here is a draft of my xUnit Cheat sheet

Update: 06.12.2011, added IUseFixture<>

xUnitCheatSheet (Currently V0.2)

Let me know if you have any updates…

.NET, Test Driven Development, Testing cheatsheet, Xunit

Since a few weeks the new mockito release candidate is available. So I think it is the right time to place a new post. Here I will show the differences between ArgumentMatcher and ArgumentCaptor. Most developer will first see the ArgumentMatcher and use it. What can be done with ArgumentCaptor is often not seen. With the sample I will show that an ArgumentMatcher should not be used to fetch arguments. For this work there is the ArgumentCaptor. The Matcher should really be used to check if an argument matches or not.

Java, Test Driven Development Java, Mockito, TDD, Test Driven Development

cross-post from www.bbv.ch/blog

In the last two years I gave over a dozen courses and presentations about test driven development (TDD). One question, I get asked almost every time, is how to refactor code while keeping up the TDD rules:

• write only production code if there is a failing test requesting it
• have no more that one failing test at once

Test Driven Development Refactoring, Test Driven Development

We use a lot of state machines in our projects. We use them for abstracting instruments that we control, controlling when user input controls have to be enabled or disabled and for other things.

State machines are great for these kind of tasks (much easier that nested switch statements anyway) but they provide a big challenge when developing software test driven. This is due to the fact that they are of course very state full and often active (running on their own worker thread).

Here are some best practices leading to maintainable and refactoring friendly unit tests.

Clean Code, Test Driven Development, Testing multi-threading, state machine, TDD, Unit Test

I’m working in an agile software development team which develops a fairly complex automation system for manufacturing facilities. We are using Test Driven Development as our main tool to improve the overall quality of the code. We all knew that we are going to have a large number of unit tests during the life cycle of the software. Before we started writing unit tests we decided that we need a test naming convention.

Agile, Clean Code, Test Driven Development TDD, test naming convention, Unit Test

I just added my short book review of xUnit Test Patterns – Refactoring Test Code by Gerard Meszaros to our books page.

Happy reading…

Agile, Announcement, Test Driven Development

Updated: new version available!

I have compiled two cheat sheets about clean code (the ones mentioned in my post about Code Quality!).

The first covers clean code – code that is easy readable and keeps changeable. The second is about Test Driven Development. Both cheat sheets list principles, patterns, practices and smells.

You can download them here – Clean Code Cheat Sheet V1.3, Clean TDD Cheat Sheet V1.2.

Take a look!

I’d like to read your feedback in the comments section…

(just an unreadable preview    – click on link in text above)

.NET, Agile, Test Driven Development .NET, Architecture, Clean Code, Design, TDD, Test Driven Development, unit testing