Don't just say you're going to invest in automation, DO IT!

So it's been a few months since I've blogged, and why? Because I'm too busy doing manual testing.

It's not my main thing. I really like the duality of testing and coding associated with automation (Watir). I'm not the best programmer, which is why I didn't go down the dev track, but I feel confident in the little corner of Watir/Ruby code I use regularly to write automation. It brings a lot of pieces and technologies at different levels together (if you're a one-man show, which is frequently the case automating UI testing) which is interesting and keeps you learning new (often random) things.

So what sucks is this is the second company I've worked for that I was hired with the promise of doing automation a large percentage of the time, and the second company that has had me do relatively little automation. The first company I did zero automation for in the course of my 5 months there. For this company I did the bulk of it during holiday downtime when not a lot of dev was going on. It was great and I remembered why I got into software, I even started a blog. Now it's back to the grind and a loss of sight of the long-term payoff automation could afford if given the investment of time.

An ounce of (high quality) automation is worth a pound of manual testing.

RSpec, should and Watir; what was the point again?

In the Watir group, I read this post about using RSpec with Watir and it still doesn't make sense to me why someone would want to use RSpec with Watir. The long and short of the thread was that someone was unclear on the syntax of RSpec
questionframe.radio(:id, "rlbYesNo_0").checked? should be_true
vs
questionframe.radio(:id, "rlbYesNo_0").checked?.should be_true

Later, others discussed the proper syntax of matchers in other veins as well, the idea of writing your own matchers, and someone brought up later that a fix had been added to RSpec because it and Watir were not playing together exactly right. http://groups.google.com/group/watir-general/browse_thread/thread/f7b72bf1742d8895

The confusion displayed, potential for incorrect syntax, time spent learning/discussing, and fact that you're introducing another layer of someone else's code to test for you which may itself contain bugs are good enough reasons for me not to use RSpec (keep reading).

I don't believe
x.should have_something

is that much clearer than
assert(x.has_something?)

I believe the more code between (the meat of) your testcase and the app under test, the more likely you are to introduce bugs (yours or someone else's) and the more time you have to spend testing your test code.

I almost wrote this post asking "why use RSpec at all?" but after looking at RSpec's homepage again I was reminded what it's real purpose is: BDD (no screwing around for reals BDD). I think that's what doesn't jive with Watir. I don't think Watir would be a great tool for BDD in most cases. I think of Watir as a GUI test tool and (if you're writing very specific, potentially lengthy tests) an end-to-end test tool. Also it's just slow. If you're doing serious BDD you need your tests to run fast and preferrably test the minimal set of your code as possible. Watir is too slow and just does too much for that.

RSpec is "pretty" in that it's almost painfully obvious (which I appreciate, I try to write obvious code), but I don't think that's the end it's trying to reach. It's real end is trying to facilitate BDD.

mic check 1, 2, 4

hello blogging world!

let's see how this thing handles...

tiny
big

bold
ital
georgiacourier
times
here's a link to google

linked centered img:ugh. why put that at the top of the page?

ok be that way, i'll reformat it myself.