James Carr

Edit: Don’t get me wrong… I still stand by my motto to “Automate All Tests” … my viewpoint here is that sometimes you should use common sense if an automated test provides zero value.

In a previous post, I ranted that we should work to “Automate All Tests.” And I still stand by my original sentiment… as professionals, we should always strive to write as many automated tests as we can to ensure quality. One posted a comment asking “How about when not to automate?” Well, I think this iteration I finally came across the scenario in a project when you shouldn’t automate.

Part of this iteration we had a few cards related to changing the look and feel of a few pages on our site (which all contained forms) and updating some of the static text. We made our changes, uploaded the images, and tested across browsers and made sure everything still worked. Then our QA (who is also a little new) asked, “Shouldn’t we have some automated tests for this card?” I shook my head no. “But shouldn’t we try to automate tests for everything?”

I think this is the case where you shouldn’t… and I’ll explain why. For starters, the UI is always a volatile place that can change frequently.. writing tests around that ensures you’ll have broken tests in the near future. Second, what business logic are you testing? Like I said before, writing a test for static text is silly… there is zero effort in adding that text, writing the test would be more time intensive, and again your test will break next time the customer wants to change it (and FFS, TDD’ing text is really plain out silly). And finally, building off the last reason, the domain is what matters most… that’s why we spend much effort decoupling our view from the model so that we can test our model in isolation.

This is why I tend to really criticize Fitnesse fixtures like HtmlFixture or even Selenium to an extent (I have found a lot of GOOD use for that tool however)… the domain language of these tests tend to be very web developer centric (elements, ids, etc) and as a result largely focus on the UI so much that they completely ignore the domain logic happening behind the scenes. IMHO a test to make sure form fields are present is a waste of time. On the other hand, a test that fills out those form fields with different combinations of data, submits them, and verifies the expected outputs is a VERY worthwhile test.

Remember the key point is to ask yourself what benefit you gain from writing an automated test, and whether that benefit is worthwhile. For me, a simple gander at the UI and asking the customer to confirm it looks good is “good enough” and gives me time to focus on writing tests for and developing the domain layer more.

And the domain layer is the most important place in you application. Period.

Labor Day weekend finally proved to close the summer with a bang, and it was worth it. Had quite an awesome time with some friends spending 3 days down in the Ozarks partying, boating, and, well, partying it up at the Party Cove. I’d have to say it was quite a fun filled and eventful summer… Cardinals games, a week of learning and partying in D.C., three visits to the Party Cove, two best friends’ weddings, and a heck of a lot more… not to mention the drinking almost every night that’s put quite a few pounds on me.

But in a way, with summer finally over, I almost feel relieved. Already I’ve headed back to doing some of the more academic things I love and enjoy. Last Friday we had an awesome, day long Agile Open Space at work, filled with all kinds of interesting sessions and workshops. What made me the happiest about this (especially since I was a facilitator for our version of “Design Sense”) was that all of the sessions were very open ended and filled with very thought provoking and interesting discussion.

Maybe my only nitpick was how I came across one of our examples for “Design Sense.” I downloaded the source code of an application that I thought would be a great example of “good” OO design, only to discover that every one of the domain objects had methods named along the lines of “getEmail_forPersistenceMapping()” with a comment above ranting about being forced to break encapsulation to work with the persistence mapping framework. Ugh… how nasty can it be when you have all of your model level objects tightly coupled with the persistence layer mapping framework??? Suffice to say this ended up being amongst the examples that were rated unanomiously bad.

Also of interest is that I have rebooted the Mid Mo XP usergroup after a lengthy break (almost a year since the last meeting). Last night we held our first new meeting, which was included doing some hands on TDD exercises that wound up sparking a lot of discussion and learning more about how we write our tests. It was pretty fun, especially having a few people outside of Carfax show up, and we’ll definitely do it again. There’s been a lot of talk about what we can do for the next meeting, some ideas we’ve kicked around would be maybe having pairs pair up, TDD code, then swap their code with another team to see what they can do to refactor and improve it. Of course, I hope to maybe rotate the coding with the non-coding aspects of XP, but keep it hands on and fun.

Overall, it’s been a good summer, and it’s shaping up to be a very fun (and educational) Fall. For now, I’m off to work on my Design Pattern class I’m teaching at work tomorrow to cover the CommandPattern, and I’m trying to cook up some code that is a prime case for applying the refactoring.