Tags: adventures in RSpec, agile, agile 2006, agile2007, antipatterns, article, baseball, being a scanner, coding standards, design, emotional health, extreme programming, java, junit, just to be clear, mac, moving, people, personality types, planning, presenting, rails, refactoring, review, ruby, speaking, stories, testing, writing, xp2006, xp2007, xp2008, xpday
Testing the UI: presentation and rendering
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.
JUnit Recipes coming soon to Safari Online
I would like to announce that Manning Publications has begun sending its books to Safari Online, the subscription-based O’Reilly service. I have found the service useful over the past three years, particularly after our flood wiped out much of my professional development book collection. If you subscribe to the service, but have not yet read JUnit Recipes, you will soon have your chance!
You're invited! "Test-Driven Enterprise Code" at XP 2008
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.
New review of JUnit Recipes
It’s nice to see that nearly five years after I started writing JUnit Recipes, people continue to read and review it. I imagined it would have become obsolete by now, especially with the proliferation of Java 5, Java 6 and JUnit 4.
The review ends with “If you use JUnit as your test tool and if you do any of the ‘things’ covered in the contents list of recipes then I recommend getting hold of this book.” I appreciate it.
