You use Spring in your application everywhere. You love it. Everything gets injected and is configured by Spring. Great. Why not use the same technology to wire up your tests?
The bottom line is: Starting the Spring Context all the time in your tests drags you down at the costs of development time.
Here is why:
1. Turnaround times are much faster
When you discover a bug which might have not been covered by tests yet (this happens to me all the time) you are much faster rerunning your tests without the application context. In the application I’m working on it takes about 20-25 seconds to run a test with application context, whereas a pure unit test just takes 1 second. Now imagine this: changing some code and rerunning tests like 100 times saves you a lot of time. The tests run faster, you don’t get distracted because you could do something else in those 20-25 seconds, like browsing some web pages (you want to be efficient and use the ‘spare’ time to read up the newest stories on infoq.com). But then you need to switch windows, read something, switch back, wonder what you did, rethink the problem and so on. In the end it costs you much more time than it seems.
2. Enables you pratice Test Driven Development
Since you can run test faster without the Spring context, you can start doing Test Driven Development. Before any line of production code gets typed into your IDE, write the test. That the code does not compile is the first test, go fix it by writing the actual stub for the class which you want to test. Now onto the next test. It fails, you implement the feature and rerun the test. This goes on and on and on until you fully implemented the requirements. It forces you only to implements the things needed and not more.
Uncle Bob’s three rules of Test Driven Development
1. You are not allowed to write any production code unless it is to make a failing unit test pass.
2. You are not allowed to write any more of a unit test than is sufficient to fail; and compilation failures are failures.
3. You are not allowed to write any more production code than is sufficient to pass the one failing unit test.
Learn more about Test Driven Development with Uncle Bob.
Without fast unit tests you just can’t do TDD.
3. No corrupt test configuration
Depending on the setup of the project you might have an extra Spring application context configuration for tests. You have to configure and keep it up to date. Things can go wrong here and will be detected very late.
If you use the application context in tests you get the beans injected but sometimes you need to mock them, because you depend on an application server, a database or an external service which you don’t want to start up every time you run tests. You must be very careful with that. Using mocks with Spring application context can be very powerful but also very dangerous. You have to make sure that you remove the mocks after you are done with your tests (and reinject the right ones) or mark the methods which are injecting mocks with the DirtiesContext annotation so Spring can reload them. I did debug forgotten DirtiesContext annotations one too many times. The mock object lives on in your context and 282 test later an exception occurs for no reason and you start debugging at a wrong place.
You will not discover those mock problems until you run the full suite of tests. Since your tests are slow you not very likely to run all the on a regular basis to see if everything plays well together. No, you run all tests right before checkin and then start to wonder why some tests somewhere fail. Depending on the size of the changes and the project it will require some substantial amount of time to find and fix the problem.
You might say: “But I need my application context in the tests. My Service which I want to test has so many dependencies, I just can’t mock them all!”
While this happened to me as well it might turn out that this service is maybe doing too much. Split the functionality into smaller packages and test them individually (that’s the S in SOLID principles). The danger in testing a complex service with mocks only is also that you might end up mocking everything and you don’t do any real tests anymore (happened to me, I threw hours of coding away).
There is one reason to run tests with a Spring application context. It’s just not in unit tests. If you want to test the integration with external services (like databases or webservices) you need to use it of course. Just make sure you really just test the interaction between your service and the external interface and not more (but even that is debatable in some cases). That’s what I call an integration test.
Do you use Spring in your unit tests? What experiences did you make?
I do work with language property files pretty much every day (since I’m the GUI guy in the team). The files are updated on different branches copied up to the trunk and merged down to new branches, sometimes even updated by our product owner. We got a couple of times into not so funny merge conflicts since people did not sort the property files in the same way. To get around that we used an external tool to sort the files just before committing them.
Right, we can do better than this.
I wrote a small plugin for IntelliJ IDEA (and turns out my colleague too) for sorting these inside IDEA. I took the easy approach to sort them in the editor window. Simply open a properties file and choose Code – Sort Properties. It detects if this is a real properties file (e.g. all lines do have a # at the start or do follow the pattern key=value) and sorts them. If things go boom you always can undo 
.
You can get it from here. It’s just 7KB since I did not include the testng jars.
In the last couple of month we continuously improved our scrum task board. After a sprint planning we usually do a story breakdown into tasks. All tasks for one story get ordered and a time for each will be estimated. We do try do make sure every task is smaller than 8 hours so it can be completed in one day.Our ScrumBoard is a magnetic whiteboard with hand drawn lines.
We do use color coded cards for the tasks we do. We do shuffle the colors each sprint but we have different colors for:
- The Story itself
- A Task
- Unplanned Task (like a thing we forgot at breakdown)
- High Priority Bugs which need to be fixed right away
- Non Sprint Tasks
Different colors make it easy to see if we were good at estimating the work which needs to be done. It shows us very easily that we might be in trouble with our commitment because we got of external tasks. The burndown chart shows this as well, but the colors show us why (as well as the bars, more on that later).
The top row is reserved for unplanned tasks, bugs and time boxed events such as workshops with the solution owner or support for the product owner. Four rows are for stories we are working on.
As soon as somebody starts a task he writes his name on the task card and puts it in the ‘work’ column. He usually takes as many cards until the added hours of the tasks equal the time he is available to the sprint today.
Each card has a specific order in which it needs to be executed to complete the story. Some tasks could be executed in parallel and some have to wait. If we find one card blocking and somebody is working on it, the rest of the team sometimes starts with a new story or helps finishing the blocker. Right next to it we draw a small bar for each day we are working on this task. When we see that a task which should take e.g. 4 hours is now in the ‘work’ column for 2 or more days then this needs to be addressed in a way that we brake this card further down or assign more people to it so this can be finished. Bar code cards are not cool.
If a task is done, we put them at the end of the row in the ‘work’ column in 90 degree angle. This card will be moved the next morning during the 15 minute daily scrum to the ‘done’ column. If something comes up during the daily scrum which needs to be discussed by the team we write this down in the Standup Backlog at the board.
To get a better impression have a look at the ScrumBoard Cheat Sheet of my team.
Update:
This is our current sprint overview:
Our current scrum board
What is Extreme visibility?
Extreme visibility is all about providing information about the code to every team in near real time. We show several metrics such as complexity of the code (xs), todo’s, deprecated methods, number of broken builds, open tickets and their priority and so on. These are distributed over a couple of screens which our software is rotating through. Every team member can easily see if his or her commits effecting the code quality in a good or bad way and makes the members aware of certain quality standards we try to keep in our code base. A typical screen looks like this (mockup):
Extreme Visibility
We discovered that showing these kind of statistics to the team has the effect that everybody in the team room cares about the numbers (and therefore the code quality). Without this display you just don’t know how your changes will effect the overall quality of the code. It might seem a bit threatening to individual team members at first (like we do show who checks in without a commit message) it turns out this is not really a problem.
While we did provide very detailed information in the past about the trunk and every branch (every user story is on it’s on branch), we found out that too many screens are counter productive and results in not caring about the values displayed too much anymore. We also do believe that showing time line and progression information on several metrics are very motivating to the team. We are planning of tweaking the information this way in the near future.
The software we use is written by ourselves in Grails. On the front end we simply have Firefox running a full screen mode. Every team has a big screen TV connected to a computer (turns out I could connect my Sega Dreamcast too). We did collect some good feedback and learned a lot about the usage in the last couple of months. The next step now is to enable the teams to write their own modules to provide the information which is the most useful to them.
I’m not aware of any open source (or other) software doing the same kind of thing. Writing it by ourselves we could tailor it to our specific needs like showing svn information, showing Teamcity build statistics or information about the code using Structure 101.
Overall the team I’m working in is very happy with the information we get from our extreme visibility monitor. XV makes sure we all can see how the quality of our code develops and we get warning signs to take counter measures to bring it back on track. And that’s what we want after all .
I upgraded my MacBook Pro last week to 4 GB of RAM (up from 2GB). It’s cheap (about 50 Euros) and it really makes a difference. I can give IntelliJ IDEA 1GB Xmx without any problem. No swapping anymore if I have Idea, Pixelmator, Tomcat, Maven, XMind, Firefox, Mail.app, Tweetdeck and NewsGator running at the same time. Why did I not do it earlier?
Today I got an interesting ctrl+space code completion in IDEA 8.1. Easteregg anyone ? 
Update: Seems like this is part of IDEA since at least release 4.0.
I do love IntelliJ IDEA but the 8.0 release had some issues with indexing and compiler caches.
Version 8.1 is out and addresses these issues (among other things, e.g. git support). Hurray.
I heard about BDD a couple of months ago and did not really pay attention. Just some weeks ago I thought that maybe I could improve our test and/or documentation. So I decided to give it a shot with the BDD implementation easyb.
According to Wikipedia:
Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.
So I took the chance to sketch out a little example and to test it against readability.
This is the class which I would to test with BDD and classic TestNG.
package net.wehrens.easyb;
import java.util.ArrayList;
import java.util.List;
public class Car {
private boolean engineInstalled;
private int doors;
private List<Wheel> wheels = new ArrayList<Wheel>();
public void addDoor() { doors++; }
public void addEngine() { engineInstalled = true; }
public boolean isEngineInstalled() { return engineInstalled; }
public int getDoors() { return doors; }
public void addWheel(Wheel p_wheel) { wheels.add(p_wheel); }
public List<Wheel> getWheels() { return wheels; }
}
The testcode in easyb looks very descriptive (and even my Product Owner can understand what’s happening). It uses Groovy to create it’s own DSL for writing tests. Even if I don’t explain any more you have a good chance to understand it at the first read.
import net.wehrens.easyb.Car
import net.wehrens.easyb.Wheel
scenario "make a new car with one door", {
given "a new car", {
car = new Car()
}
when "a door is added", {
car.addDoor()
}
then "car should have one door", {
car.doors.shouldBe 1
}
}
scenario "make a car with an engine", {
given "a new car", {
car = new Car()
}
when "an engine is added", {
car.addEngine()
}
then "the car should have an engine", {
ensure(car.engineInstalled)
}
}
The TestNG version of this test looks a little bit tighter but not as easy to understand for non programmers.
package net.wehrens.easyb;
import org.testng.Assert;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;
public class CarTest {
private Car _car;
@BeforeMethod
public void setUp() {
_car = new Car();
}
@Test
public void testAddEngine() {
_car.addEngine();
Assert.assertTrue(_car.isEngineInstalled());
}
@Test
public void testAddDoor() {
_car.addDoor();
Assert.assertEquals(_car.getDoors(), 1);
}
}
The big advantage I see here is that non technical people could be able to design test, how the code should behave, what the results should be. This is an often underestimated problem when communicating with the requirements engineers. Just write the BDD tests and the developers make sure they will turn green. The neat thing is that easyb has maven 2 integration and an IntelliJ Idea plugin. This makes working with it a breeze.
Sure sounds easy, but I by myself did not had a chance yet to try that out in a more complex environment…maybe stuff for a later post.
After about a year of not blogging, I’m getting back to it. I have still some infrastructure work to do but it’s coming. Just wait a little bit more.
