Agile .NET

Ideas & Gotchas

Archive for the ‘Extreme Programming’ Category

TDD – Create test objects automatically

Posted by Vlad on September 13, 2007


Unit tests normally have three sections: setup, action and validation. In the setup part you often have to create and initialize objects that will be required by the action and that you can use in the validation part to decide whether the code works or not.

The code might look like this:

      [Test]

      public void DoSomethingWorksFine()

      {

            MyObject obj = new MyObject();

            obj.Text = “test text”;

            obj.ID = Guid.NewGuid();

            obj.Date = DateTime.Now;

            // etc.

            testedObject.DoSomething(obj);

            // asserts

      }

Although normally one or two initialized properties are enough, I consider it a good practice to check that all the fields pass well through the test (especially when you’re testing database repositories or web service calls). The problem is that if you use the default values you won’t know if the test passed just because the result has the same initial values.

My solution is a handy utility class that fills the objects properties with random data:
Read the rest of this entry »

Posted in C#, Extreme Programming, TDD | 2 Comments »

Agile adventures – Ideal time vs. Real time

Posted by Vlad on September 4, 2007

Bolitas
When programmers estimate their tasks, they normally use “ideal time” – time spent exclusively on the task, with no interruptions and in a good work disposition. When you bill the client, you have to take into account the real time the programmers use to get the job done – we billed by the hour so we also delivered a detailed log on how each hour was used.

One of the confusing aspects of XP is that you have the programmers estimating their tasks with the client present. So if the client pays for 40 hours / week of programmer work, he’ll have a tough time understanding why the programmer only signs up for 15 or (if you bill by the hour) why he is billed 6 hours for something that was estimated as 2 hours.

As I see it, there are two options:

  1. make one estimated hour equal to one real hour
  2. “train” everyone to treat the estimated hours as something completely unrelated to real time.

Read the rest of this entry »

Posted in Agile, Extreme Programming | Leave a Comment »