If you are familiar with hamcrest and JUnit the time will come when you have
the need to create your own matchers.
Creating your own matcher can be as simple as useful. One reason for
creating your own matcher could be that your object is not a default object
like a String or a Collection. And if you would like to get a more readable
version of the assert for the next developer who has to read your
test. Let’s make an example. If you have an object with two methods;
“getName” and “getNumber” and you would like to check whether the resulting object
has the correct values.
In my opinion the best way to verify this is to create two matchers and
combine them. Before we can combine these two matchers let’s see how to
create them. Continue reading
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. Continue reading
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.
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.
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.
Senior Software Architect
bbv Software Services AG
urs.enzler _at_ bbv.ch (replace _at_ with @)
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.
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.
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. Continue reading
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