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

Are you tired of using the object property in MOQ?

Are you tired of declaring a huge amount of local variables to declare complex hierarchies?

…

Have a look at the new Mock.Of<T> feature in MOQ! Let’s see an example.

.NET, Agile, Test Driven Development, Testing Mocking, mocking framework, Moq

Did you had the problem your mock must act like a bean? And you could not create the object with the real implementation? And the interface was too large, so you would not create a innerclass for the test? I had this problem too. I solved it with the answer in mockito.

Java, Test Driven Development, Testing answer, ejb, Java, Mocking, Mockito, TDD, Test Driven Development

This is a small summarization what the differences are between the different variations creating mocks with mockito.

Null values (default)

Per default, after creating a mock, every method will return null. Just create your mock with:

Sample sample = Mockito.mock(ISample.class);

I think, this is very useful and straight forward. (And based by mockito developers idea, to create very fast a mock for testing). Sometimes it is very difficult to determine an error which was produced through such a null value. For this case it is very practicable to tell mockito, returning SmartNullValues.

Agile, Java, Test Driven Development, Testing Agile, Java, Mockito, TDD, Test Driven Development, Testing

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 AG

How to get quality into source code – that’s the question I’ll try to answer in this document.

You’ll see what we do at bbv Software Services to get code that is built with inherent quality and why it is important to think about quality throughout the whole development process.

Agile, Presentation, Test Driven Development Acceptance Tests, Agile, Collective Code Ownership, Continuous Integration, Development, Pair Programming, Presentation, Refactoring, scrum, TDD, Team Learning, Test Driven Development, Testing, Unit Test

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.

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

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