I recently read Jeff Patton’s column at StickyMinds. His latest article tells us the secret to automated acceptance tests. I responded, and I include that response here.

I like this article, Jeff, but I’d like to point out that programmers can automate more tests in advance without risking a ripple effect when a customer wants to move a field around.

We know that many designs exhibit high coupling between “the UI” and “the logic”, and teasing that coupling apart—mostly moving (business) logic out of the UI—is one step towards more flexibility, less ripple effect and more valuable automated end-to-end tests. We have all seen it. I invite programmers to take one more step.

Inside “the UI” I find two major kinds of code: UI toolkit client code and more general toolkit-neutral code. When I format a monetary amount as ”$12.50”, I can make that decision without involving the UI toolkit; but when I decide to display the text ”$12.50” as a label or in a text field, I need to involve the UI toolkit in that decision. I invite programmers to separate their UI into presentation logic (UI toolkit neutral) and rendering logic (UI toolkit specific). If you do this, you will have an “abstract UI” or “presentation layer” you can test without drawing a real UI. These tests run quickly because they run in memory without having to paint a screen or invoke a UI toolkit component of any kind. You don’t need end-to-end tests here. When someone decides to move a field around, none of your presentation layer tests need to change, and you avoid the ripple effect. Yes, your end-to-end tests change, but over time you’ll automate fewer of those, preferring instead to automate the presentation layer tests.

So programmers, do your worst! Introduce a true presentation layer into your design, starting with the next screen or page. You’ll thank yourself, and maybe me.

Discuss

Allow me to invite you to XP 2008 in Limerick, Ireland on June 11, 2008 at 2 PM local time to join me for Test-Driven Enterprise Code, my long-running tutorial aimed at programmers who want to practise test-driven development in the complicated world of platforms, frameworks, libraries, and more. Stay tuned to this channel for presentation slides, and possibly more.

Discuss

Another in the Enerjy TV series. This time, the question is “How do you believe McCabe Complexity helps programmers?”

Discuss

I have spent the last two days with Mary and Tom Poppendieck at one of their Practitioners Courses, and I find myself inspired. Among the interesting moments for me was a point at which I reached an unsettling notion: are we “too Western” to design software well?

I came to this question while watching course attendees talk about the problems in their organization. As they explored the flow of value through their IT organizations, I kept hearing about managers interrupting the flow and of centralized decision-makers as bottlenecks, when it occurred to me: I’ve heard about these problems in code before.

Specifically, I heard the word “manager” and my mind wandered towards thinking of Manager classes in a code base, rather than flesh-and-blood managers. In that wandering instant I saw a connection between the two kinds of managers: human managers have mostly commonly been trained over the last century to micro-manage, make important decisions and direct their people; and Manager classes do essentially the same thing in code. Now, while our ideas of management have changed in the past 50 years, mostly due to the work coming out of Toyota, we are still over-run by micro-managers whose effectiveness is limited.

It’s quite similar with code. In spite of the object-oriented design movement and the advance of test-driven development with its emphasis on simple design, procedural thinking dominates, even in code bases that use object-oriented languages. Most programmers approach code with Procedural Mind, even when they believe they want to design with objects. Even when I teach people how their can arrive at excellent designs by following four simple rules, Procedural Mind dominates.

So I wonder: given the parallels between tactical, command-and-control management and highly procedural code where important decisions are centralized in these Manager classes, and given that our most common human management style is a relic of western military thinking, and given that it perpetuates in part due to culturally-entrenched ideas about managing people, are Western programmers conditioned against excellent design? Are we mostly doomed to gather our code in Manager classes, rather than distribute responsibilities evenly and focus on object interaction?

Are those notions simply too Eastern for us?

Discuss

Just a quick one. I’ll write the proof later.

People commonly complain to me that when they try to test-drive code with test doubles (say with JMock), they end up with brittle tests: when the code changes, all these tests change. I understand, because it used to be that way for me, too. Nowadays, it doesn’t cause me a problem, and I believe it’s because my interfaces tend to stabilize quickly, and I believe that happens because my interfaces tend to be minimal with appropriately-distributed behaviors. How did I get to design so well?

When JMock told me my tests were brittle, I changed my design so that the tests were more robust. The result, as a side effect, was smaller, more cohesive interfaces and less coupling between classes and their collaborators.

Discuss