A few weeks ago on the TestDrivenDevelopment mailing list, Ron Jeffies, one of the XP gurus, stated that "in order to obtain good code, writing tests and code is faster then just code". To find out if this is true or not let's make a small experiment here.

Suppose your company develops a java web application for a company. The project involves very complex physics formulas to do reports on different medical measurements. Two years later, they want to make a significant change in the application, but keep the existing functionality in place? What do you do? How Selenium helped me do this very complicated task in a month here.

Using automated tests that depend on a database can always be a tricky task. Although this is usually avoided using mock objects, I tried to write a simple sample of how to use Test Driven Development to build a sales report. The example can be found at: TDDing the sales report and it includes the source code.


Download: Sources

Source code: Download

Lately, I have noticed that the Humble Dialog Box or Model View Presenter are gaining more and more acceptance among software developers, especially in agile communities, because of its benefits regarding the very good separation between the view and the behavior and because it can be very easily unit tested, on a problematic field: user interface.

1. Introduction

A lot of waste and rework is done because of bad communication. In fact, communication is the main factor in a project success or failure. And that does not refer only to software. Alistair Cockburn, wrote an entire book about the importance of communication and builds a methodology around improving communication: the crystal family

2. The big misunderstanding: improving means increasing quantity

One day I heard about eXtreme Programming. Wow, I was a student, eager to know, and I tried to live on the edge. Extreme was just what I looked for. Soon after I got Kent Beck's - Extreme Programming Explained, the first edition. I read it very fast and that was a decisive moment in my programming life. I thought everthing in there was good but not appliable. I said , you can never have 100% unit tested code. In time I saw I was wrong. I said PP costs double. I was wrong. Every practice was for me a new impossible and as the time got by, I found it less and less imposible but as the book said very beneficial.