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