Test driven development is hard. Perhaps it would not be if we were taught to think about OO development from a TDD perspective in the first place; but those muscles are poorly developed, and the exercise leaves you sore and panting a bit. As with physical exercise, there is a reward in the pain. Perhaps others do not see it, but I can already see the benefits accruing in Reggie as I rebuild it with SOLID principles in mind, driven by tests. To help me consolidate where I’m going, and help others whose TDD muscles are likewise under-developed, let us walk through a test, shall we?

First, some context. I’m working on adding persistence to the application: ability to save and re-open session data. I have a ViewModel, called ReggieBasicViewModel, which initially contains the data to persist and which binds the View to my business logic. The ViewModel is being instantiated with a factory object, which allows the ViewModel to build concrete instances of various dependencies. This illustrates the Abstract Factory pattern, and the Open-Closed Principle, but arguably violates Single Responsibility Principle [same link as OCP] by grouping un-related functionality into the factory. The proper factory object is configured in the application’s bootstrapper class, or or it is setup in a unit test using an alternate factory implementation.

Let the heavens rejoice, let the earth be glad;
    let the sea resound, and all that is in it.
Let the fields be jubilant, and everything in them;
    let all the trees of the forest sing for joy.

Psalm 96:11-12 (NIV)

Let us do all humanly possible to preserve and restore heavens, earth, sea, fields, and trees — before we find ourselves alone in our worship.

Moles is a powerful and useful framework for unit testing. Or was. But even then, it was overused (at least by me). But no more!

The first clue that I might need to walk away from Moles was the recent difficulty another developer was having in trying to get a unit test project up-and-running on his computer. I had installed what was current in early 2011, and he had installed the current version from last 2011. Turns out there was a significant change – the config file no longer worked. We had to update the assemblies correctly on my machine, rebuild many times, and fool around with manually removing some assemblies. It got confusing and messy. I suppose that's why MS still labeled this version as < 1.0.

For several years now, I have been relying on Microsoft’s Moles for isolating one method from another in my unit tests. Recently I’ve begun to understand that this was not the best approach. I’ll dig into that more in a future post. Having come to this conclusion, I need to start ripping out Moles. Based on the user feedback across the web, and the powerful Lambda expression syntax I’ve grown used to, I’ve chosen MoQ as my replacement. Now for an exercise…

In preparation for Earth Day next weekend, I was reading a bit of Love God, Heal Earth this morning. I was reminded of the passage about "love thy neighbor as thyself", and its implications for the ethics of sustainability. Who is your neighbor? Does it include someone a state away? In another country? Continent? What about the people of the future? This famous passage can be interpreted, in modern context, as a call for eco-justice, which includes leaving a sustainable way of life for future generations. Matthew, chapter 22, verses 36 - 39 (NIV)

"Teacher, which is the greatest commandment in the Law?"

Jesus replied: "‘Love the Lord your God with all your heart and with all your soul and with all your mind.’ This is the first and greatest commandment. And the second is like it: ‘Love your neighbor as yourself.’"

Here’s an interesting scenario: I have a Linq-to-Entities query that is giving me no results when performing a system test, but when I look in the database, logically there should be results. Better yet, the unit test passes. How can that be?

A common challenge for development teams is remembering the names for all of the different servers in an enterprise environment when the server naming convention is either not descriptive ("Deathstar", "Falcon", "XWing") or obscure ("abcDBS001", "abcDBS002", "abcWEB01"). The Star Wars names suffer from an obvious problem of mapping description to purpose. Those obscure names are commonly used to help distinguish between dozens to hundreds of different servers in an enterprise. Arguably they are helpful to the infrastructure team as they manage this motley collection. But for a developer, remembering if "abcWEB01" is the test web server or prod can be challenging; even when remembered, it would be simple enough to overlook or accidentally type "abcWEB04".

Historically I've advocated naming test methods after the method under test, in order to help find the tests when you need to modify them. Growing Object-Oriented Software, Guided by Tests has shown me that this is a relic of a code-first mentality rather than good application of test driven development, primarily in the section "Test Names Describe Features" (ch 21). "Test driven" development implies that we do not know the name of the method we're going to test. But we do know the functionality (feature) that we are going after, and that knowledge should be used when writing out a test name. For example:

Vanderbilt University, a large private school in Tennessee, is enforcing rules that require all student groups receiving on campus funds to open up membership to anyone - including officer positions (story on NPR). Naturally, this is of great concern to Faith-based organizations in particular: one can easily imagine a group of atheists gate-crashing a meeting and electing their own leader to be the President/Chair/Grand Poobah of the _ <insert religion> Association_.

For years I've had problems with SSIS deployments to production. In fact, I completely abandoned SSIS packages because it was so difficult to deploy to production (in SQL Server 2005): I always ended up with errors that would require me to hand-edit the file and hard-code paths. That, despite the fact that my config files have the database connection strings and file paths in them. And despite the fact that my packages usually work fine on the test server but fail in production. After years of this problem, it suddenly occurred to me that one piece in particular is probably at fault. But given that I do not have access to production such that I can investigate, it will always be a hypothesis: using a template that sets various properties with the help of variable expressions.