This might be a "duh!" thing but...

it was a new concept for me. I always wondered why some of the methods in the Watir RDoc didn't have any documentation. I asked Bret Pettichord about it, and it basically the gist is that if a method isn't documented, you can assume it is a non-public interface (not to be called directly).

I'm sure this is probably how things are normally done in the programming-language world, but it was new to me. Thanks to Bret for providing this insight.

Integrating Ruby testing in Intellij and TeamCity...made easy

One of the greatest things about scripting languages is that they can work entirely through the command line and require very little in the way of infrastructure.

For example, in my environment at work, our development environment is Java, and the tools are very Jetbrain-centric. They use Intellij for their and IDE and (more important for me) use TeamCity for continuous integration. This has two implications for me:

1. JetBrains has a Ruby plugin for Intellij which works really well, so I can use the same dev environment as our developers, even though I'm working in Ruby. It has code highlighting and code intelligence, and generally works well. I'm also playing with RubyMine, a Jetbrains all-Ruby IDE. It is based on Intellij so it has a great editor, but also supports Rake and has a nifty GUI test runner. Right now it's in "free preview mode", I'm told when it releases it will be $99, which seems pretty reasonable.
2. One requirement I had when I started working for McAfee is that our component-level tests integrate into our TeamCity environment, so that test runs could be scheduled to be kicked off and so that test results would be easily viewable by anyone on the team at the location they are already going to. This was easy, because TeamCity has a "command line" option for it's build runner. That means anything that can be kicked off through the command line can be scheduled to run. Of course, this includes RSpec-enabled Ruby scripts. Since RSpec includes an option to output to HTML, and since TeamCity has a way of pointing to build "artifacts" to view from their website, I just set up my configuration so that the script outputs to an HTML file, and then pointed to that HTML file as my build artifact. In this way, I can run Ruby tests and produce an HTML report in the TeamCity environment.
   

Customizing watir-console

Watir comes with a really cool command-line tool called watir-console. To start it, just type watir-console at a prompt (assuming you have the ruby\bin directory in your path). It will bring up an irb prompt, but this isn't just any irb prompt. It has already required the watir module, and offers some cool features for interactively using Watir, such as tab completion of Watir commands.

One thing you can do to make watir-console even more useful is to write a startup script. Here are the steps:

1. Create a helper script and put it in one of the Ruby library directories (such as C:\ruby\lib\ruby\1.8). Let's call it helper.rb.
2. Create a .irbrc file (just a text file) and store it in \ruby\bin. This is actually a Ruby file, and can have any Ruby commands you want to start up when Ruby starts. For our purposes, your script should 'require' the script you built in step 1.

That's it! Now, helper.rb (and its methods and constants) will be available in watir-console whenever you run it.

"What should I put in helper.rb", you ask? I'm a believer in examples, so here are a few examples of methods I created:

• A 'login()' method to start a browser, go to the login page for my web app and log in. It returns the IE object, so it can be called from watir-console as "instance = login()". This allows you to then access "instance" as the IE instance to be manipulated.
• Now you can run different methods to do different things. For example, my application does queries, so I have a 'new_query()' method that simply navigates to the page where I can create a query. It is accessed by calling 'new_query(instance)' from watir-console.

This makes Watir and watir-console indispensable in interactively testing web applications.

Peter Cooper lists 23 useful Ruby 1.91 links...check them out, I have (well, most of them)

Here's the link...

My personal favorite...Dave Thomas' "Fun with Ruby 1.9 Regular Expressions"

Ruby Design Patterns - an epiphany

I’ve been reading Russ Olsen’s great book, Design Patterns in Ruby. I’ve always had my developer friends tell me design patterns are a great thing, the jelly to your peanut butter, the Martin to your Lewis if you are a software developer. I gave it the typical…”huh…I’ll have to check that out...sometime.”

No longer.

As have been reading Olsen’s book, I am realizing, it has far-reaching implications that go beyond just writing a Ruby class efficiently. For instance, one of the principles is “separate the things likely to change from the things likely to stay the same.” This sounds simple…and it is. But it’s also incredibly powerful. Have you ever created a large suite of manual test steps, only to have the software change and need to re-write virtually all of them? If you apply this principle, your manual test scripts will be more durable and more flexible. And it didn’t involve writing a single line of Ruby (or any) code. It simply involved applying a true principle.

Take a look at this book…it will definitely cause you to think in a different way. And that’s always a good thing.

Brett Pettichord working on new Watir testing framework

Brett Pettichord's latest blog post has some information on a new Watir-based testing framework. It looks pretty interesting. Since I use Watir extensively for my testing work, I have a particular interest in Brett's work.

I guess my initial question is...what exactly does it provide that Watir/RSpec doesn't? I might download and play with it some...will blog about my impressions.

MountainWest RubyConf 2009 - see ya there

I’ll be at the Mountain West RubyConf 2009 in Salt Lake City March 13-14…if you’ll be there, look me up. I hope to make some good contacts in Rubyland and learn some stuff. Besides, my work is paying for the conference, so who can beat that?

Also, I may be presenting to the Software Association of Oregon (SOA) in the near future about Ruby, Watir and RSpec (and how to build a web testing framework using them). Stay tuned.

The idea behind this blog

I’m a software qa engineer who works with Ruby, Watir and RSpec every day, and I noticed there weren’t any blogs out in the ’sphere for folks like me. So, here I am. I often have more questions than answers, but I figured maybe if I just start writing, others might find something here that’s useful too.

Welcome to my black-cloud-qa-type, Ruby world.