Today I met Matz. The creator of Ruby.

This is might not be a big deal for others who have been going to the lone star ruby conference for a while, but I got to finally hear Matz today.

I snapped a quick picture along with two of my team members from HomeAway. I am the guy on the right.

Matz used his keynote to talk about features to come in the next version of ruby such as  scoped monkey patching, module prepending, lazy mapping, and ruby keyword arguments.

He also mentioned mruby, that is coming soon.  I checked out the source and ran the tests. Here is the source link https://github.com/mruby/mruby/

download the source and run ‘make’ and ‘make test’.  You will then find mruby, mirb in the bin directory.

James,Alan, and myself with Matz.

 

Managing browsers from the command line on OS X

Have you ever wanted to open a url from the command line on OS X?  Turns out open can do many cool things like that.

open -a ‘google chrome’ ‘http://www.scottcsims.com’

open -a Firefox.app http://www.scottcsims.com

Sometimes a parallel Selenium run might get out of control and you need to close all your browsers, try this one from the command line:

killall firefox

Yes, I know killall is a very old Unix command, but I didn’t know that I could pass it an application name that a OS X has bound to an executable.

killall firefox-bin
or
killall firefox

I like the -a and -e options for open.

Usage: open [-e] [-t] [-f] [-W] [-R] [-n] [-g] [-h] [-b ] [-a ] [filenames] [--args arguments]
Help: Open opens files from a shell.
      By default, opens each file using the default application for that file.  
      If the file is in the form of a URL, the file will be opened as a URL.
Options: 
      -a                Opens with the specified application.
      -b                Opens with the specified application bundle identifier.
      -e                Opens with TextEdit.
      -t                Opens with default text editor.
      -f                Reads input from standard input and opens with TextEdit.
      -F  --fresh       Launches the app fresh, that is, without restoring windows. Saved persistent state is lost, excluding Untitled documents.
      -R, --reveal      Selects in the Finder instead of opening.
      -W, --wait-apps   Blocks until the used applications are closed (even if they were already running).
          --args        All remaining arguments are passed in argv to the application's main() function instead of opened.
      -n, --new         Open a new instance of the application even if one is already running.
      -j, --hide        Launches the app hidden.
      -g, --background  Does not bring the application to the foreground.
      -h, --header      Searches header file locations for headers matching the given filenames, and opens them.

Minesweeper Programming Contest. Using Selenium Web Driver to win Minesweeper

I had a great time attending the Test Automation Bazaar  in Austin. Alister Scott put on a contest to see who could write a program to win Minesweeper.  After checking out what was required, I started coding the Minesweeper robot. Before I noticed, I had spent hours coding tests and methods for the robot.  It was one of the most addictive and exciting code I had written.  I spent about 3 days coding along to get something to win on basic and intermediate level. I spent hours trying to win on advanced.

I ended up winning the Minesweeper Challenge!  I encourage everyone to take a look at Alister’s code.  Alister wrote some of the  best cukes and examples I have seen.  I was very impressed by the time he put into writing unit tests that work on logic only, taking the browser out of the mix.  Thanks Alister for putting on the contest.  If you wish to see what 3 days of coding gets you in a mine sweeper robot you can checkout my code on github.  As I mentioned before I got really engaged with writing this code.  I could have spent weeks tuning and polishing it.  I did have a chance to refractor the code to use Nokogiri instead of the find all elements selenium method to check the game state.  I believe that this might have actually slowed it down.

Sadly to say, I had to withdraw from polishing and tuning the code.  If you want to run my robot checkout the code and run the test “Minesweeper should win” in this file.

 

What does the SeleniumFury generator find on a page for you?

What should you expect SeleniumFury to find on a page for you?   Take a look behind the curtains at the PageParser class on git hub.
You will find that I am using Nokogiri xml parser to find elements and you will see this list of html elements that I am looking for.

          @nokogiri_selectors= ["select",
                              "textarea",
                              "form",
                              "input",
                              "input[type='button']",
                              "input[type='file']",
                              "input[type='checkbox']",
                              "input[type='password']",
                              "input[type='radio']",
                              "input[type='reset']",
                              "input[type='image']",
                              "input[type='submit']",
                              "input[type='text']"]

The only fields that are found are simple HTML fields.

For more complex UI elements like jquery select menus, I usually will define the class and write a unit test for the actions that can be done on the component.
You can use the page method on PageObject to define a subpage or page component like this.

  
class SelectMenu < PageObject     #This could be a jquery select menu     element :select_menu, {:id => "selectSomething"}
    def select index
      #code to select
    end 
end
class SearchPage < PageObject
     #add the component to your main page
     page :select_menu, SelectMenu
end
#Use your page component
SearchPage.new(driver).select_menu.select(2)

I have more examples of this in the SeleniumFury source. See this PageObject Unit Test(spec)

STPCon session submission. What do you think?

An Automated Test is Real Code!

Session Information

An automated test is real code! We should follow good programming practices even when automating tests. Use Session-Based Test Management to explore you system under test. Model your automation design before you get started. Write test first unit tests to help build your page objects. After your page objects are built, make them portable to use in different test suites such as functional, conformance, and cucumber tests. Organize your continuous integration jobs to tell you pinpointed information about your system under test.

Selenium Fury is on RelishApp.com

Checkout Selenium Fury on relishapp.com. I found the site when I was searching for Rspec2 documentation. The site organizes your cucumber features into a really nice presentation so that your features can be consumed as documentation. It has been a great tool for learning more about Rspec 2. To illustrate the difference this is what it is like to view Features on github and here is the same feature on rellishapp.

Selenium Fury 5.5 released

I was able to restructure the gem and remove the dependency on Rspec. I have tested successfully with Rspec 1 and 2.

Lightning Talk From Selenium Conference

Checkout my lightning talk on SeleniumFury the page object factory for Ruby.
Lightning Talk From Selenium Conference

Selenium Fury 5.2 with custom generators has been released.

The latest release of Selenium Fury is ready for your install.  Checkout the new cucumber features at the project home  https://github.com/scottcsims/SeleniumFury. This version includes extended page element recognition, custom generators, and the git hub project includes support for bundler and rvm.

Install the new release:   gem install selenium_fury

https://rubygems.org/gems/selenium_fury

 

What I liked about “Perfect Software And Other Illusions About Testing” by Gerald M. Weinberg

Perfect Software And Other Illusions About Testing
Perfect Software And Other Illusions About Testing

I recently finished reading “Perfect Software and other illusions about testing” by Gerald Weinberg.  I wanted to elaborate and reflect on a few points I enjoyed about the book .  I recently attended the Software Test Professionals Conference and Gerald Weinberg was there signing his book. I had not heard of him at that point, but now I will be at the front of the line for the next book signing.

The first chapter was a home run, it was titled “Why do we bother testing?”  I found that this statement shed new light on an old subject for me.

“Common mistake 5: Believing testing can improve a product: Testing gathers information about a product; it does not fix things it finds that are wrong.  Testing does not improve a product; the improving is done by people fixing the bugs that testing has uncovered.  Often when managers say, “Testing takes too long” what they should be saying is, “Fixing the bugs is the product takes too long, ” — a different cost category. Make sure your accounting for effort and time under the correct cost category.”

Chapter four is titled  “Whats the difference between testing and debugging”.  I found two interesting answers about locating faults and pinpointing that I was not expecting.  I remember thinking at one point in my testing carrer that if I could find a defect and then locate in code the source of the problem that I would be considered an amazing tester. Who should pinpoint failures?

“Common mistake 4:  Demanding that testers pinpoint every failure:  Testers can help developers with this job, if there time has been scheduled for it, but it is ultimately a developer responsibility.  At least that’s what I’ve seen work best in the long run. “

“Common mistake 5:  Demanding that testers locate every fault:  This is totally a developer’s job, because developers have the needed skills.  Testers generally don’t have these skills, though at times, they may have useful hints.”

In chapter thirteen different strategies are discussed for determining significance.  Significance is the importance attached to the bug by the person who gets to decide what to do about that bug.  I liked these four categories for determining the significance of an issue from a testing point of view

Level 0: This issue is blocking other testing.
Level 1:  Our product cannot be used if this issue isn’t resolved
Level 3:  The value of our product will be significantly reduced if this issue isn’t resolved.
Level 4:  This issue will be important only if there are large numbers of similar issues when the product is shipped.

From the high level project view, think about your project and how important fixing is.   I learned that fixing is linked to an emotional value that is given to every fixable work item.  It is possible that every member of the team might assign a different emotional value to ever fixable work item.  In this case, how do you manage what gets fixed in what order if all members of your team members have different values assigned to your fixable work items? I like the summary of chapter thirteen to answer this question.

“Our emotions carry information about how important things are. If we pay attention to emotions, listen, and address important matters before unimportant matters, we’ll be doing the best we can with the data we have.”

In conclusion I highly suggest this book for anyone developing or testing software.  It will also be helpful to anyone making decisions about how software is released or built.