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

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

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

The Model View View-Model pattern gained a lot of momentum lately. It allows to reduce the code in the code behind class of a form or user control to a minimum. Therefore, unit testability is improved dramatically compared to other view patterns like MVC/MVP.

However, when I design software, I follow (amongst others) the principles of SOLID (link).

The first principle in SOLID is the Single Responsibility Prinicple (SRP) that states that “A class should have one, and only one, reason to change.” (link)

And here start my concerns about MVVM.

.NET, Architecture .NET, Architecture, Design, Passive View Command, Patterns, Unit Test, unit 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

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