Plus has a lot of extra flexibility and settings and to be honest I can live with out on all my machines, but on the Linux box it does give a little extra peace of mind and flexibility. So for my situation:

Purchase Crashplan Central:100%
Purchase Crashplan Plus:50%

Thanks for the update. Do you use Crashplan or Crashplan plus? …does the “instant” backup that plus provides versus daily backup from the free version make a difference to you?

I think I’ll buy the crashplan central now after reading your article. I too was (am) a Memopal user but it causes me constant disk drive activity which my anti-virus software gets very excited about!

You could maybe do it as follows:

implement the data source factory so that it gets a reference to the spring context somehow and then get the data source from it and return that as instance.

Currently the whole setup with spring and unitils is not ideal.
Spring now also has the test listener concept. In a next release we’re going to make unitils use these test listeners directly and also make it possible to do all config from spring.

That way you can just use the spring base classes and still hook into the unitils modules.

The unitils spring module will then become deprecated.

brgds,
Tim

Am I missing something?

Point 2. I think tests should evolve and improve with the system and should be treated in the same light as production code. I.e they should be well written and as you say, reviewed.

Point 3. Hey I have been transient staff! As such left high coverage behind because the test can answer questions I might not be around for.

There is something that can help. Scrum has this concept of “Definition of Done.” Its a contract for a task. I think an example says more than a description so for a simple service method you might have something like this:

Method written.
Method code reviewed, test coverage, findbugs output checked. Eclipse warnings cleaned or suppressed.
Appropriate unit tests checked.
Appropriate integration and performance tests checked.
Release note updated.

And so on. The idea is that the task can not be in the sprint review until all tasks are done.

The team gets to decide what is an appropriate definition of done, but the scrum master and or product owner can be involved in the discussion.

My thoughts on the subject of reward:

To my experience, TDD and code quality can actually bring their own rewards. A codebase with good coverage and good assertions is harder for others to subsequently break if they try to expand your work for reuse or attempt optimisations (premature or legitimate). Failure cases can obviously be environmental or as a result of integration, but subtle problems introduced at the unit level have a way of snowballing into show-stoppers for an entire application. Good unit and integration tests can trap this at build time.
The reward? Fewer late nights spent trying to deduce how a regression got in or weekend phone calls when someone else’s change takes out the app. Free time is its own reward. More time with the wife/kids/television or alternatively fresh new tasks on a project, so you can be an innovator on the team rather than a maintenance man. I’d rather be consistently working on new challenging pieces and leaving work at a reasonable hour rather than any quantifiable reward. Well maybe not ANY reward…

The problems:
1 – project managers don’t always appreciate the value of TDD: it doesn’t give burn down. A false economy, since the team will just spend far more having to go back and fix simple bugs that could’ve been trapped more quickly earlier.
2 – other people can change your tests as well as your implementation. Unless your tests were bad in the first place, you should not accept any excuse from @Ignore writers. They could even be asked what their legitimate case is to modify the behaviour of an existing piece of code – are they changing a contract? Their unwillingness to spend 5 minutes extending a test is potentially going to cost you an evening or a weekend.
3 – transient staff. If people are only in teams for very short periods, the benefits from TDD are less apparent to them. Holding people accountable is hard enough if they move functional area, forget about it if they move teams or leave the company. This is why code reviews MUST include test cases.

Agreed.

It would be interesting to build in reward systems that reward teams who achieve results through Agile systems. I am more in favor of rewarding teams than individuals…but that is another story.