In his blog on web GUI testing, Uncle Bob presents an example using RSpec.

There are a couple of things that I’ve begun to approach a bit differently, and I’d like to present them for your consideration and comment.

Testing GUIs is one of the the holy grails of Test Driven Develoment (TDD). Many teams who have adopted TDD for other parts of their projects have, for one reason or another, been unable to adequately test the GUI portion of their code.

In this series of article I will show that GUI testing is a solved problem. Over the years the TDD community has produced and accumulated tools, frameworks, libraries, and techniques that allow any team to test their GUI code as fully as any other part of their code.

Being perhaps more terse than precise, I provided this as a response to “What is a good Architecture”:

I would say that a good architecture is one in which a solution can be built, tested, and deployed, and within which all points of maintenance are singular and well-placed.

Now it’s nothing new, and nothing earth-shatteringly well said maybe, but I think it’s the first time I’ve successfully managed to express what I want.

Put even more vaguely and more tersly, I could say “it works and I can continue working in it”, but that actually says less than I want.

I serendipitously received two things today. One was a link to an article on procrastination and the other was an email about YAGNI. It took me a moment or two to realise that they are talking about the same thing. In the procrastination case, it’s seen in a more negative light, and in the YAGNI case it’s exalted.

The phrase from the procrastination article that really hit me was that procrastinators “value today more than tomorrow.” That’s what Agile is like, too.

Maybe Agile is partly about creative, productive procrastination?

In the movie City Slickers, weathered cowboy Curly told the clueless ranch noobs that he’d found the secret of life. He held up his index finger, and announced “One Thing.”

I suspect that Curly had a mighty good idea, that you should be able to do one thing supremely well instead of doing and being all things. For all our units of software, One is a very friendly number, indeed.

In a recent article at Agile Journal there is a nice quote from John Cunningham, regarding the tendency of metrics-collectors to major in minors

I listen to all these analysts (professionals) tell us that the keys to winning are running the ball (increasing time of possession) and stopping the run (decreasing the opposition’s ability to control the ball). Nonsense! These are not the keys. Scoring more points than the opposition is the key

There article continues to recomment useful ways of measuring the success of an agile project. It is of particular interest to organizations transitioning to agile.

The reason the DailyWTF is so funny, is that we all secretly identify with it. Here’s my latest WTF.

Many years ago I read an interview with Pat Metheny in which the interviewer asked him about how he approaches practicing scales. This is from memory from a long time ago, so forgive any misquotes (and if anyone can help me find the text of the interview I’ll be glad to update this post), but he responded with something like “Scales are an important part of improvising and there are elements of scales in everything we play. But practicing scales by themselves isn’t that interesting. Why would you want to play a scale when you could be playing a tune?”

I’ve heard other musicians talk about this in terms of “if you practice scales you’ll play scales on the gig”. I believe this to be true, and can be found manifested in the music of many who like to call themselves jazz musicians.

That always resonated with me as an aspiring musician, and has manifested itself within my sensibilities about software as craft. This relates to why I’ve latched on to BDD and the surrounding conversation.

Focusing on internal state and structure in your tests is like practicing scales. The end result is often code that is clean in a vacuum, but doesn’t express its intent well – just like hearing that guitar player running scales up and down (again). It may use the most theoretically efficient techniques, but it fails to tell a story.

Focusing on observable behaviour in your tests is like practicing melodies. The result is that your code is more likely to express its intent. It’s more likely to be just the right code for that particular requirement. Just like the improvisor who always plays exactly the right thing for that moment.

DRY (Don’t Repeat Yourself) is a very useful guideline. As with all principles, however, there is a tendency to apply it as a golden rule without really thinking about why it is meaningful, and therefore not understanding when it is important to use and when it is not.

There is another principle that sometimes conflicts with DRY: Clean Code!

Communication between web clients and servers is dominated by strings. This leads to complex and horrific problems of coupling, and fragility. Where are the rules?