Firefox Hacks

Posted by indomitablehef | Filed under Tools

I loves me some Firefox. Occasionally having to use IE now seems like too much to ask, but sometimes there is no way to avoid it (like when editing docs in SharePoint). Usually, Firefox is pretty lean on resources too, but after having it up all day running apps like GMail, GCal,Google Docs, and Google reader, posting to my blogs, and running ASP.Net apps in debug mode, it can get a little heavy, and start chewing up memory. This post describes several ways to reduce the memory used by Firefox. Most of it is common sense, like turning off extensions and plugins, but the part I really dig is a config setting that will tell Firefox to release memory when it is minimized. Check it out here.

Collapse All

Posted by indomitablehef | Filed under Visual Studio

This is a “collapse all” macro for Visual Studio 2005. It gets annoying having to scroll up and down, expanding and collapsing folders. Sometimes, it would be nice to just tell Visual Studio to collapse everything, and start clean. This little macro does just that.

It’s pronounced Co-Burn

Posted by indomitablehef | Filed under Agile

Interesting audio interview with Alistair Cockburn over at itconversations.com, where he discusses agile development and some of its history. I enjoyed it, and recommend the book, too.

Test Driven Development

Posted by indomitablehef | Filed under TDD

Following a regrettable gap in posting (I’ve been busy buying a house these last few days), we’re back.

Test Driven Development is one of those things that sounds great when you first hear it. Climbing up on the bandwagon is relatively easy. Test Driven Development, however, is not. At least, it hasn’t been for me. I’m still unsatisfied with my level of mastery over it. Like any good ideologue, however, I am determined to make it work.

Actually, I’m not an ideologue about testing at all. I’m not one of those “everything must have a test” types. I prefer some kind of RTDD, or perhaps TFDWIMS (ReasonableTestDrivenDesign or TestFirstDesignWhenItMakesSense). Trouble is, it’s hard to know when to be strict about testing, and when not to. It helps to realize that Test Driven Development is not primarily about “testing” in the traditional sense. TDD is often sold solely on the basis of being able to do regression testing when something changes. The impression is that after the first release of an application, when the users request new features, they can be added by development, all the tests run, and the application will have no bugs. That’s all well and good, but it’s not the whole story…it’s not even the best part.

The most important reasons to do Test Driven Development have nothing to do with supporting future enhancements to an application, on a large scale. That is not to say that such projects will derive no benefit from a TDD approach, but if that is why you are planning to adopt TDD, you’d be better off investing in an automated testing software that can run usage scripts against your application, building detailed regression tests, and keeping them updated as you enhance your product.

No, TDD in the real world is really about something else, something smaller, something closer to the core of your software. First of all, TDD is a useful design tool. When implementing a feature, use case, or enhancement to your application, it is often illuminating to sit down and develop a Test Driven plan for how to proceed.

Let me give you an example. I’m about to begin working on an enhancement to an existing application, dealing with Patients and medical insurance Claims. The existing application already manages Patients, but it calls them “Members” (as in members of an insurance plan). The existing application has no Claims information in it, but I have a source database with the claims, related to Patients, that was supplied by the insurance plan (my client). I’m going to be making a lot more changes to this application in the future, and I intend to begin creating a rich domain model. I’ve already been learning about the domain and modeling what I’ve learned with business stakeholders.

My goals then, are as follows:

1. refactor Member into Patient - Patient is part of the core of the domain model. I want to clarify that concept, and then build on it for future releases.
2. add Claims data to the Patient, so that users of the application can see a Patient’s Claims history.

I’ve decided that I need a PatientFactory. The Patient class is going to get more and more complex as I build out the domain model, so having a Factory that knows how to build a Patient will be useful in the future, and will keep me from having to clutter up the Patient class with the details on exactly how it is built.

So, I’ve come up with the following Test Driven Development Plan.

1. Write the PatientFactory Test Setup
   In the Unit Test’s Setup Method, add known Patients to database table, using SQL scripts.
2. Write PatientFactory Test TearDown
   In the Unit Test’s TearDown method, add SQL delete commands to remove the known Patients added during Setup
3. Write the PatientFactory Test: PatientFactory can retrieve a single known Patient by Id
   Notice that I haven’t even created a Patient or PatientFactory class yet. This test will fail.
4. Implement PatientFactory.GetById (probably under a better name)
   Create the Patient Factory Class
   Create the Patient Class, converting the old Member Class into a Patient
   Re-use the existing data access code (happens to be ActiveRecord pattern) to retrieve Member/Patient data from the database.
   Implement PatientFactory.GetById - keep going till the test passes.
5. Write Unit Test: PatientFactory can retrieve a list of known patients
6. Implement PatientFactory.GetList method
   Until test passes.
7. Implement the changes made all the way through the application to the UI, to test the refactoring of Member into Patient. Change the labels, docs, everything. Complete the refactoring of Member into Patient.
8. Leaving out some steps here…testing/refactoring/implementing the update/delete features for Member/Patient.

Moving on to Claims:

1. Still in the PatientFactory Test suite, Add to the Test Setup
   Insert Claims for known Patients into the database, using a SQL script.
2. Add to the PatientFactory Test TearDown
   Sql Delete script to remove the claims we added during setup
3. Write the unit test: Patient Factory can retrieve a single known Patient along with that Patient’s claims history.
4. Implement the Claims class, update data access for Patient/Claims, add to PatientFactory code that will add the Claims to a Patient when a Patient is built. Stop when the unit test passes.
5. Write Unit Test: Patient Factory retrieves a list of Patients (without claims), and then returns a single Patient selected from the list With Claims.
   So, essentially, we are lazy loading Claims History.
6. Implement the “lazy load” feature in the PatientFactory
7. Implement Claims all the way through to the UI, web controls, docs, etc.
8. Implement sorting for the Claims History in the UI

Thinking through the features I intend to implement, using a Test-First approach, can actually help clarify and simplify your design decisions, and result in a useful checklist of sorts to help you move quickly through the development of features.

The real raison d’être for Test Driven Development is what happens next. Now that I have the beginnings of a test suite, and the beginnings of my core domain model, I will begin the process of refactoring. Notice that I did not write unit tests for displaying Patients, displaying Claims, or sorting lists of Patients or Claims. These things are trivial. The emerging domain model, however, is not. In future iterations, I want to add relationships between Patients and Providers, Care Plans, Risks, Interventions, and Outcomes. As I grow this domain model a little at a time, I will write the tests first, add new domain concepts, and when I’ve finished, run the domain layer unit tests I’ve created to validate the correctness of my core domain. As the model matures, I may well learn that some things that I once thought “belonged” to a Patient are really the child of some other class in the model. When that happens, I will restructure my tests, refactor my domain layer to match my new understanding, and re-validate the model through running the tests.

Test Driven Development enables effective refactoring of the domain model to a richer understanding of the domain. Use it for that and don’t try to write tests for every trivial detail. When you write your class first, then use your Unit Testing software (Visual Studio, NUnit, others) to “Generate Unit Tests”, it will generate a test class that contains test methods to check to see that every property get/set in your class works. What a complete waste of time! Write your test first, test only the important stuff, and get on with building something useful.

Some Reading on Test Driven Development:

Introduction to Test Driven Design (TDD) at AgileData.org
Extreme Testing
For anyone using Visual Studio Team System’s testing features, a very useful little tidbit.