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.

My Response

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.

References

Jeff Patton, “Secrets to Automated Acceptance Tests”.