IT Really Matters

Real Life Photoshop

Sat, 04 Feb 2012 13:15:27 +0200

Real Life Photoshop

Browser Wars

Thu, 12 Jan 2012 18:33:59 +0200

Browser Wars

Today’s Marriage

Wed, 07 Dec 2011 17:00:06 +0200

Today’s Marriage

Harmless Checkin

Wed, 30 Nov 2011 17:02:05 +0200

Harmless Checkin

Freaky Wireless Technology

Wed, 23 Nov 2011 17:01:05 +0200

Freaky Wireless Technology

Speedup Ruby 1.9.3 On Windows

Thu, 17 Nov 2011 00:37:00 +0200

Ruby is a great programming language, but unfortunately it does have some problems when using on Windows. One of it’s biggest drawbacks is it’s slowness when loading files. This is also slower than it ought to be on Unix platforms, but not as slow as on Windows. Thankfully there is some work going on to make it faster in future versions. It’s already possible to make it faster yourself!

Benchmarks

I will conduct two types of benchmarks. Firstly i’m gonna create an empty Rails 3 project and see how much time would it boot up. Secondly there is a project called measurements which allows to perform some operations on your Ruby and one of these are benchmarks for loading files. Let’s see how it goes for Ruby 1.9.2, 1.9.3 from RubyInstaller and patched 1.9.3.

# ruby 1.9.2p136 C:\>rails new empty-192 -d sqlite3 # ... Using rails (3.1.1) C:\empty-192>timer ruby script\rails runner "" user system total real 0.000000 0.016000 0.016000 ( 28.808579) C:\measurements>rci bench core_require_empty && rci bench core_require_nested ruby 1.9.2p136 (2010-12-25) [i386-mingw32] Rehearsal ------------------------------------------------------ core_require_empty 2.917000 7.722000 10.639000 ( 10.755556) -------------------------------------------- total: 10.639000sec user system total real core_require_empty 3.167000 7.815000 10.982000 ( 11.133547) ruby 1.9.2p136 (2010-12-25) [i386-mingw32] Rehearsal ------------------------------------------------------- core_require_nested 3.556000 8.736000 12.292000 ( 12.453693) --------------------------------------------- total: 12.292000sec user system total real core_require_nested 3.526000 9.188000 12.714000 ( 13.157714) # ruby 1.9.3p0 from RubyInstaller C:\>rails new empty-193-p0 -d sqlite3 # ... Using rails (3.1.1) C:\empty-193-p0>timer ruby script\rails runner "" user system total real 0.000000 0.000000 0.000000 ( 17.425940) C:\measurements>rci bench core_require_empty && rci bench core_require_nested ruby 1.9.3p0 (2011-10-30) [i386-mingw32] Rehearsal ------------------------------------------------------ core_require_empty 3.120000 9.937000 13.057000 ( 13.278704) -------------------------------------------- total: 13.057000sec user system total real core_require_empty 3.167000 9.578000 12.745000 ( 13.231747) ruby 1.9.3p0 (2011-10-30) [i386-mingw32] Rehearsal ------------------------------------------------------- core_require_nested 3.822000 11.373000 15.195000 ( 15.853803) --------------------------------------------- total: 15.195000sec user system total real core_require_nested 3.822000 11.653000 15.475000 ( 16.779881) # Ruby 1.9.3p0 patched C:\>rails new empty-193-faster -d sqlite3 # ... Using rails (3.1.1) C:\empty-193-faster>timer ruby script\rails runner "" user system total real 0.000000 0.000000 0.000000 ( 9.184323) C:\measurements>rci bench core_require_empty && rci bench core_require_nested ruby 1.9.3p0 (2011-11-08 revision 33661) [i386-mingw32] Rehearsal ------------------------------------------------------ core_require_empty 2.620000 5.616000 8.236000 ( 9.144510) --------------------------------------------- total: 8.236000sec user system total real core_require_empty 2.247000 5.179000 7.426000 ( 7.930452) ruby 1.9.3p0 (2011-11-08 revision 33661) [i386-mingw32] Rehearsal ------------------------------------------------------- core_require_nested 2.496000 5.522000 8.018000 ( 8.123630) ---------------------------------------------- total: 8.018000sec user system total real core_require_nested 2.652000 5.960000 8.612000 ( 8.861500)

These benchmarks show that Ruby 1.9.2 is really slow and patched 1.9.3 got about 50% performance boost compared to regular 1.9.3. That’s something to be happy about! I’m using average laptop PC which means that if you have a more decent hardware then the results might be very different from me.

Prerequisites

The following components are needed to speedup your Ruby:

Ruby 1.9.3 from RubyInstaller
Devkit
Git

If you’d like to skip all that hassle of building all the things yourself then you can download already prebuilt patched Ruby versions too! Read the “Faster Way” part about that below.

Get Fenix

Fenix is a Ruby extension written by Luis Lavena. Luis is a really helpful and great guy, at least when it comes to Ruby on Windows. He is part of the Ruby core team, is the main man behind RubyInstaller and has created many nice libraries like sqlite3-ruby, rake-compiler and many others.

Back to Fenix. It changes File.expand_path method to be faster. All the 50% speedup seen from the benchmarks were coming from this change since this method is called more than once when loading files. Pretty impressive or rather sad bottleneck in Ruby. Get the Fenix extension, compile and benchmark it:

C:\>git clone git://github.com/luislavena/fenix.git Initialized empty Git repository in C:/fenix/.git/ # ... C:\>devkit\devkitvars.bat Adding the DevKit to PATH... C:\fenix>rake compile # ... install -c tmp/i386-mingw32/fenix/1.9.3/fenix.so lib/fenix.so C:\fenix>rake bench File.expand_path: 10000 times. user system total real Ruby '' 0.297000 0.593000 0.890000 ( 0.884027) Fenix '' 0.062000 0.000000 0.062000 ( 0.066004) Ruby '.' 0.312000 0.546000 0.858000 ( 0.876040) Fenix '.' 0.062000 0.000000 0.062000 ( 0.060000) Ruby 'foo', 'bar' 0.312000 0.983000 1.295000 ( 1.328060) Fenix 'foo', 'bar' 0.078000 0.000000 0.078000 ( 0.106003) Ruby '', 'C:/' 0.031000 0.000000 0.031000 ( 0.031000) Fenix '', 'C:/' 0.047000 0.000000 0.047000 ( 0.050000) Ruby 'foo', 'C:/' 0.171000 1.965000 2.136000 ( 2.248100) Fenix 'foo', 'C:/' 0.047000 0.000000 0.047000 ( 0.054003) Ruby '~' 0.530000 0.562000 1.092000 ( 1.111063) Fenix '~' 0.094000 0.000000 0.094000 ( 0.100006) Ruby '~/foo' 0.468000 0.827000 1.295000 ( 1.321076) Fenix '~/foo' 0.078000 0.000000 0.078000 ( 0.076005) Ruby 'foo/' 0.280000 0.624000 0.904000 ( 0.917052) Fenix 'foo/' 0.078000 0.000000 0.078000 ( 0.071004) Ruby '~', 'C:/Foo' 0.375000 0.717000 1.092000 ( 1.110063) Fenix '~', 'C:/Foo' 0.093000 0.000000 0.093000 ( 0.090005) Ruby long_path 0.203000 0.016000 0.219000 ( 0.214006) Fenix long_path 0.203000 0.000000 0.203000 ( 0.207005) Ruby long_path, 'rel' 0.421000 0.734000 1.155000 ( 1.237058) Fenix long_path, 'rel' 0.234000 0.000000 0.234000 ( 0.227013) Ruby long_path, 'C:/Foo' 0.375000 1.981000 2.356000 ( 2.470126) Fenix long_path, 'C:/Foo' 0.187000 0.000000 0.187000 ( 0.184010) Ruby full_long_path 0.156000 0.015000 0.171000 ( 0.170010) Fenix full_long_path 0.156000 0.000000 0.156000 ( 0.183011) Ruby to_path 0.234000 0.359000 0.593000 ( 0.619036) Fenix to_path 0.062000 0.000000 0.062000 ( 0.071004) Ruby to_path, 'rel' 0.468000 0.999000 1.467000 ( 1.455083) Fenix to_path, 'rel' 0.094000 0.000000 0.094000 ( 0.091006) Ruby to_path, 'C:/Foo' 0.390000 2.262000 2.652000 ( 2.844161) Fenix to_path, 'C:/Foo' 0.078000 0.000000 0.078000 ( 0.090005) Ruby full_to_path 0.390000 1.950000 2.340000 ( 2.526143) Fenix full_to_path 0.031000 0.000000 0.031000 ( 0.044003)

Not bad benchmark results.

Patching & Compiling Ruby

Unfortunately only File.expand_path method is faster when using this extension, but there’s Ruby’s require and load methods, which also execute expand_path, but they will do so by using internal C expand_path function instead. Solution for that problem is to patch Ruby code to use Fenix.expand_path internally also! First step would be to clone Ruby itself (make sure that line endings are not converted by Git):

Apply the patch created by Luis:

C:\ruby>git clone git://gist.github.com/1360449.git expand_path-patch C:\ruby>git apply -v expand_path-patch\0001-make-load-and-require-use-file-expand_path-and-file-realpath.diff Checking patch file.c... Checking patch load.c... Applied patch file.c cleanly. Applied patch load.c cleanly. C:\ruby>git status # On branch ruby_1_9_3 # Changed but not updated: # (use "git add ..." to update what will be committed) # (use "git checkout -- ..." to discard changes in working directory) # # modified: file.c # modified: load.c

`git status` shows us that file.c and load.c files are modified. It’s time to start compiling Ruby itself. Best way to do that would be to use RubyInstaller itself (how ironic, we’re using Ruby to build Ruby). Make sure to disable ANSICON too since it is known to cause problems during the compilation process:

This takes some time and if the process raises any errors, just try again. If there’s still errors don’t hesitate to write to RubyInstaller mailing list or contact Luis directly. He’s very helpful, as i already stated above.

After the process is done “install” new Ruby with Fenix and make sure that it’s used by setting environment variables too:

C:\rubyinstaller>xcopy /E /I sandbox\ruby19_mingw \ruby193-faster # ... C:\rubyinstaller>cd ..\fenix C:\fenix>xcopy /E /I lib \ruby193-faster\lib\ruby\1.9.1\i386-mingw32 lib\fenix.so lib\fenix\replace.rb 2 File(s) copied C:\fenix>set PATH=c:\ruby193-faster\bin;%PATH% C:\fenix>set RUBYOPT=-rfenix/replace

Make sure that the PATH and RUBYOPT environment variables are set permanently. And try it out if it’s faster for you too!

Faster Way

In case you don’t want to spend your time cloning, compiling and testing then there is a faster way to boost your Ruby. There exists a project called The Code Shop, which tries to solve the Ruby performance problem on Windows. It makes different builds available to download, each experimenting with different set of patches. I can recommend tcs-ruby193_require_winio_fenix-20111113 because it seems to be the fastest. Here are some benchmark results:

# tcs-ruby193_winio_fenix-20111113 C:\empty-193>timer ruby script\rails runner "" user system total real 0.000000 0.000000 0.000000 ( 6.802955) C:\measurements>rci bench core_require_empty && rci bench core_require_nested tcs-ruby 1.9.3p0 (2011-11-08) [i386-mingw32] Rehearsal ------------------------------------------------------ core_require_empty 2.044000 2.589000 4.633000 ( 4.726269) --------------------------------------------- total: 4.633000sec user system total real core_require_empty 1.778000 2.746000 4.524000 ( 4.652266) tcs-ruby 1.9.3p0 (2011-11-08) [i386-mingw32] Rehearsal ------------------------------------------------------- core_require_nested 2.075000 3.603000 5.678000 ( 5.779272) ---------------------------------------------- total: 5.678000sec user system total real core_require_nested 2.028000 3.526000 5.554000 ( 5.791128) # tcs-ruby193_require_winio_fenix-20111113 C:\empty-193>timer ruby script\rails runner "" user system total real 0.000000 0.000000 0.000000 ( 5.635120) C:\measurements>rci bench core_require_empty && rci bench core_require_nested tcs-ruby 1.9.3p0 (2011-11-08) [i386-mingw32] Rehearsal ------------------------------------------------------ core_require_empty 1.497000 2.948000 4.445000 ( 4.571255) --------------------------------------------- total: 4.445000sec user system total real core_require_empty 1.326000 3.151000 4.477000 ( 4.577208) tcs-ruby 1.9.3p0 (2011-11-08) [i386-mingw32] Rehearsal ------------------------------------------------------- core_require_nested 1.732000 3.650000 5.382000 ( 5.529468) ---------------------------------------------- total: 5.382000sec user system total real core_require_nested 1.716000 3.604000 5.320000 ( 5.437311)

Fenix is already precompiled into these builds. You still need to ~~compile and install Fenix and~~ set PATH and RUBYOPT environments as described above.

In Conclusion

The main point of this post is that things aren’t always as rosy as they could be, but it’s possible to make them better. It is really valuable that you give feedback to projects like The Code Shop (e.g. what are your benchmark results) so the final result could get better in the future without any additional hassle for everyone. I hope that you can now start your engines much faster!

An Update is Available for Your Computer

Wed, 09 Nov 2011 22:33:39 +0200

An Update is Available for Your Computer

Awesome Page Objects In Testing

Wed, 02 Nov 2011 17:41:00 +0200

I mentioned page objects in the post about WatirSplash 2. In this post i’m gonna explain what these things exactly are and how to use them.

What Is A Page?

When it comes to automated testing then the page is really nothing else than the page user sees when visiting the website. Any meaningful page consists of different components some of which just show information (e.g. text) others allow interaction (e.g. text fields and buttons). Different pages might also have some shared content like header, search field and footer. One important thing about components is that the result of some interactions is another page.

Let me bring you a concrete example. Let’s look at the Bing’s main page (enough of Google in all examples, alright). You can think of the possible sections (Web, Images, Videos, News and More) as a header. There is also the search field and button. Search button is special since clicking on it changes the current page to results page. Makes sense? Let’s see how to convert that information into WatirSplash Page Objects.

Point Of Having Page Objects

The point of having Page Objects is to have better structured code and keep it DRY in your tests too. This all makes your tests easier to maintain. If you’re a software developer then you care about these things when it comes to production code. Why not to use these good practices in tests also? Page Objects make it all possible. Having Page Objects means that it should be easier to change your tests if the application under test (AUT) changes since you need only one place (ideally) to change. Page Objects also make it very clear where to find existing and put the new code.

Let’s Get Rockin’ With Pages And Objects

Let’s get more concrete. I assume that you have created a WatirSplash 2 project already. If not then follow the instructions in the post about WatirSplash 2 or read everything you need to know straight from the README. Let’s create the Main page first:

C:\my_project\ui-test>watirsplash page main --url http://bing.com create lib create lib/app/page/main.rb exist spec create spec/app/page/main_spec.rb

This command created us the Main page object and a test for it. The generated file looks like this:

And the test itself is nothing fancy yet:

Let’s add something meaningful to our Main page object like search field and button:

You can use all the familiar Watir methods directly in your Page objects! For the sake of clarity let’s also add Header functionality. To do that we’d just use Ruby’s mixin functionality - the Header module:

And make sure to include it into your page object:

We can now update our main_spec to actually test something:

# spec/app/page/main_spec.rb describe App::Page::Main do let(:main_page) {App::Page::Main.new} it "has header with sections" do main_page.sections.should have(5).items end it "allows to search" do main_page.search_field.set "watirsplash jarmo" results_page = main_page.search_button.click results_page.results.count.should == 10 results_page.results[0].text.should =~ /watirsplash/i end end

I made two tests - one for the header and another for the search functionality. Since header should be on every page, i could have taken advantage of the RSpec’s Shared Examples feature, but for the sake of this post’s clarity i didn’t.

The second test is a failing test since there’s no way that Watir’s Button#click will return us a results page object. But hey, i’ve just done a little TDD here! Let’s make it work like we want it to work:

I’ve used the WatirSplash::Page::Base#modify method which takes some object as it’s first argument (here button) and a Hash as a second argument. Hash consists of method name as a key and value as Proc object. In this particular case the code above overrides this particular button’s #click method with my #click, which returns Results page object due to the usage of #redirect_to method. Since #click is already existing method on that button, then it will call the original method (e.g. performs the actual clicking) before calling the defined block. The #modify method does all that by using Ruby’s meta-programming. You can always look at the source itself if you’re more interested in the nitty-gritty details.

Let’s create ourselves a Results page object with the results method. This time, let’s be even cooler and generate more code than we did with the Main page object:

This generated us the Results class with the results method:

Let’s add the #count and #[] methods to our #results object by using #modify again so we could chain method invocations naturally as i’ve written in the search functionality test:

# lib/app/page/results.rb module App module Page class Results "wg0"), :count => lambda {results.lis(:class => "sa_wr").size}, :[] => lambda {|i| results.li(:class => "sa_wr", :index => i)} end end end end

I’m invoking the #results method again to get the Watir::Ul element to execute regular Watir methods on it - in these cases #li and #lis. This neat trick hides the implementation details from the tests and makes the tests even more natural to read.

In Conclusion

That’s it - we have created a few tests using Page Objects functionality in WatirSplash 2! Using Page Objects makes your tests (hopefully) more readable and easier to maintain. I like my implementation when compared to others because it makes your page objects to look really succinct and doesn’t add any additional complex API to learn - you can use already learnt Watir methods as you did before. And the code written to support creating and using these Page Objects is also quite clever and short. I love it! I hope you will too.

Solutions To The Hardest Problems

Tue, 18 Oct 2011 12:37:56 +0300

Solutions To The Hardest Problems

Angry Birds Anger Management

Sat, 08 Oct 2011 10:39:55 +0300

Angry Birds Anger Management

Facebook, Watir And Testing

Tue, 04 Oct 2011 00:19:19 +0300

I’ve known some time now that Facebook has been using Watir as their integration testing tool. Hell, there’s even a Facebook logo on the main page of watir.com. But today was a special day because i had to read one article about Facebook moving away from Watir.

Confusions

Since i’m one of the few core developers of Watir then this article made me notice statements which are not true or are just misleading. It seems to me that the author of that post doesn’t know the insights of Watir and other tools he’s mentioning or just uses wrong terminology by accident.

Watir & JavaScript

First statement which forced me to questioning myself was the following: “Watir automates the browser with JavaScript…”.

It took me some time before i understood that the author had FireWatir in his mind and not the Watir itself. FireWatir was used to automate Firefox browser and it truly used JavaScript as it’s engine to perform all the automations. Watir on the other hand controls Internet Explorer and uses it’s OLE interface instead to control the browser. This means in effect that there’s almost no JavaScript used in Watir.

Watir != Watir-WebDriver != WebDriver

The next statement causing confusion is: “The Watir we adopted in 2009 has since been improved, integrating a new protocol called WebDriver which allows you to automate the browser more accurately and with more power than could previously be done with straight JavaScript.”

First - Watir has been improved indeed when compared to year 2009 :) This is a good thing and a true statement. Second - Watir doesn’t integrate with the new protocol called WebDriver - it does still use OLE. I’m not exactly sure what the author means by the end of his statement about more accuracy and power. And of course - third - as mentioned already, Watir itself doesn’t use JavaScript and didn’t even do that in the year of 2009.

I think that you can call the WebDriver as a protocol, but the most famous implementation of that protocol is for sure Selenium-WebDriver aka Selenium 2. Watir-WebDriver is a library written on top of Selenium-WebDriver’s Ruby bindings. In other words it is an improved API over Selenium’s API. At least this is the way, we, Watir-loving people like to think. It does even have some API improvements which vanilla Watir doesn’t have yet. There is a project called WatirSpec, which is the specification for Watir’s API. Even Watir itself doesn’t conform to that yet. But the ultimate goal is to make Watir-WebDriver and Watir 100% compatible with each other. Latest releases of Watir have been moving towards that goal.

Abandoning Watir

And then i have to read the saddest statement of that article: “Once I understood all these factors, my course of action seemed clear: Abandon Watir, create a WebDriver client in PHP, and reuse our mature PHP unit test system for our browser tests. The WebDriver protocol was straightforward enough that I had a fully featured client in PHP by the end of a weekend’s work.”

On the one hand i’m happy that the engineers in the Facebook try to make things better - having the same technologies used between different projects is always a good thing. On the other hand i’m not sure i understand as to why they had to create a new PHP WebDriver bindings. Looking from the main page of Selenium 2 i can see that there’s already two seemingly active projects doing just that - php-webdriver-bindings and WebDriver-PHP. Maybe engineers at Facebook had good reasons why not to use something already existing. Maybe they just like to feel more challenged and want to invent few bicycles in a while. I don’t know.

Conclusion

After all it was an interesting read. Since i’ve used Watir about 4 years now then it’s nice to read that someone else had similar or completely different solutions to the same problems. I like the thing about Facebook that it tries to be more open to the world when it comes to the topics of the tools and processes used to make, maintain and release such a widely used product.

On the other hand, posts having false information in them tend to have a strong effect on people using the tools under fire. Especially if this kind of information is originating from a trustworthy source. From that post it seems that it is time to abandon Watir since it is too old and not developed anymore. That’s just plain wrong. Watir is still actively developed and one of the biggest reasons why not to abandon Watir at this moment is that it is still the best automation tool for Internet Explorer. Watir-WebDriver’s IE driver is just not mature enough. Sorry, WebDriver guys. I would be happy to run all my tests with Watir-WebDriver since that would give me an opportunity to test with different browsers, but as long as IE is not working properly, then i just can’t do that. Since IE is the brittlest and still most used browser, then testing with that browser just seems to be mandatory.

I have to agree that if the person is not tied with all or some of these projects on a daily basis then it is hard to understand the difference between Watir, Watir-WebDriver and WebDriver. Maybe the biggest problem is just that the topics aren’t documented enough?

Fighting Against Gem Hell

Tue, 06 Sep 2011 23:12:25 +0300

There is a term called DLL Hell which in my opinion exists also in the Ruby community with the different name - Gem Hell. This potential problem exists when dependencies for your project and/or libraries are not managed properly.

I’ve written in the post WatirSplash 2 about loading all the dependencies with the help of the Bundler, which helps to organize the dependencies in a sanely way and tries to eliminate the Gem Hell problem. In this post i’m gonna give a more detailed overview of how the things were before and how they are now in the WatirSplash framework.

Story Behind WatirSplash’ Dependencies

Since WatirSplash is a framework which supports using different frameworks for browser automation (Watir, Watir-WebDriver and FireWatir) then there needs to be some kind of a mechanism for defining the install and runtime dependencies. Install dependencies are easy to specify since they can be put right into the .gemspec file of the WatirSplash gem and RubyGems does all the heavylifting:

It gets trickier when it comes to specifying the runtime dependencies. “Why runtime dependencies at all?” - you might ask. The answer to this question is fairly simple - because the framework used for automating the browser is chosen during runtime and it’s not possible to put all these gems into installation dependencies due to the problem of Watir (for controlling the IE browser) not installing successfully on Linux or OS X operating systems for obvious reasons. There are also other OS-specific gems. Also, it’s not possible (at least not in my knowledge of) to specify platform specific dependencies right into the .gemspec file itself.

The Old Way

The runtime dependencies in WatirSplash 1 were loaded with the help of the RubyGems itself. When the desired framework was specified then WatirSplash loaded the appropriate file, which executed the code similar to this for Watir:

It meant that the user of WatirSplash needed to have the Watir version 2.0.1 installed and if he didn’t then the installation instructions were provided.

This solution seems to solve the problem of specifying runtime dependencies at first. There are still some problems with this approach. First of all, if Watir has a dependency for some other gem without any specific or with too loose version then it is possible that some newer version of that gem breaks the usage of WatirSplash and i, as a maintainer of the WatirSplash gem, have to release a new version of the WatirSplash gem by specifying the exact version of that gem as a runtime dependency. Second problem is that if a newer version of Watir (or any other among the runtime dependency gems) were released then it was not possible for the user of WatirSplash to try if it was working with the current version of WatirSplash (which was pretty often the case) without modifying the code of WatirSplash itself or waiting for the new release made by me with updated runtime dependencies. These are the two main and quite big problems with this approach.

The New Way

These problems were solved by introducing the usage of Bundler. Bundler allows to specify runtime dependencies exactly like with RubyGems, but it has a difference of locking down the dependencies versions. This means that user A and user B are always using the same versions of all the runtime dependencies no matter what other versions they have installed on their system.

By using WatirSplash 2, you will get the following Gemfile into your specs directory, when running new project generator, for specifying all the needed dependencies:

source :rubygems # load WatirSplash and it's dependencies gem "watirsplash", "2.1.1" platforms :mingw, :mswin do gem "watir", "2.0.1" gem "win32screenshot", "~>1.0.5", :require => "win32/screenshot" end gem "watir-webdriver", "~>0.3.1" gem "firewatir", ">= 1.9.3" gem "rspec", "~>2.6.0" gem "spork", "~>0.9.0.rc9" # add your project specific dependencies here: # gem "ruby-debug", "0.10.3"

After executing `bundle install` do not forget to add Gemfile.lock also into your VCS - this is the only way to guarantee that everyone who is running the tests are using the exact same versions of the dependencies.

This solution allows each user of the WatirSplash to specify their own dependency versions without any need to wait for the new release of the WatirSplash itself. In other words - this solution solves both of the problems existent in the previous RubyGems solution.

Conclusion

Bundler tries to make the Gem Hell problem disappear and is doing a pretty good job there, but if there are gems which depend on some external native library, which needs compilation then there is still the danger of having a wrong version of that dependency causing compilation errors. Probability of seeing that problem is quite low compared to the problems which Bundler solves. All in all Bundler is a really great tool and thanks to that WatirSplash has gotten even better.

I have been using the screenshot to obtain IE screen captures. This works well when have a remote desktop session to the IE virtual machine. However, I notice that the capture is a black screen when there is no remote desktop session even though the user session still exists.

Sun, 04 Sep 2011 14:31:49 +0300

Yes, that is a known limitation Windows blocking these system calls when the PC is locked. You can use VNC or some similar remote desktop alternative which emulates the remote PC in a different way and not locking the PC when you disconnect from the remote session.

WatirSplash 2

Thu, 18 Aug 2011 20:45:00 +0300

WatirSplash 2 has been released already some time ago, but i haven’t covered the nice things which came with it. This situation will be improved with the following posts.

New Features

The biggest changes in WatirSplash 2 compared to version 1.x are:

Loading all dependencies with the help of Bundler.
Fixed support for Ruby 1.9.
Introduced so called Page Objects.
Removed cumbersome and usually not needed “ui-test-common” functionality.
Made WatirSplash more transparent making it easier to follow what, when and how it does the things it does and giving better control over it.

Removed Features

It is quite easy to understand from the “New Features” list that projects generated with WatirSplash 1.x won’t work out of the box with WatirSplash 2. I had to break backwards compatibility due to the decisions made in the past which were in my way improving the framework to make it just a lot better.

I’ve paid attention to the users of WatirSplash and noticed what they didn’t like or what they have been wanting to do differently. This has caused me to use .rspec file to configure RSpec all the way instead of doing it programmatically from the WatirSplash itself. This gives a better control for tuning the usage of RSpec when needed.

Even browser window won’t be opened and maximized automatically anymore - you can still do it with the help of RSpec.configure block.

All these little details should make the experience of using WatirSplash even better!

Getting Started

Starting to use WatirSplash is as easy as splashin’ in the water. First you have to install the gem itself ofcourse:

After doing that you’d need to generate a default project structure. It can be done by using the “new” generator:

Being inside of the newly created project directory, install all the required dependencies aswell:

After having that done, generate the very first Page Object with the “page” generator. For example:

C:\my_project\ui-test>bundle exec watirsplash page search --url http://bing.com create lib create lib/app/page/search.rb create spec create spec/app/page/search_spec.rb

There you have it. Modify the newly generated files and start specc’ing. There will be a more thorough posts about the main new features including how to use Page Objects in the future - stay tuned. Feel free to read more information about WatirSplash from it’s repository at GitHub.

Take a smile :)

Thu, 28 Jul 2011 19:08:12 +0300

Take a smile :)

Viva la RAutomation

Wed, 22 Jun 2011 18:26:00 +0300

Watir 1.9.0 got recently released. One of the biggest changes in that version, addition to the support for IE9, is a replacement of AutoIt with RAutomation! This means that the next time you’re installing Watir, you will lose all the functionality of AutoIt automatically. If you used it somewhere specifically to do something, then this post will try to help you to make the upgrade process less painful.

The Bad News About AutoIt

Let’s pretend you have something like this in your test:

Statement like this was pretty normal - you could use AutoIt directly from Watir. When you try to do the same with Watir 1.9.0 you will get an error like this:

This happens because there isn’t even anymore any method called autoit in Watir.

Quick & Dirty Fix

There are two ways to fix that problem. You could initialize your own AutoIt object and use that or you could use RAutomation’s AutoIt adapter. You can switch the adapter to AutoIt before loading Watir by setting the environment variable called RAUTOMATION_ADAPTER to “autoit” before loading Watir itself:

Of course this is not a good solution, after all AutoIt was replaced by RAutomation with having best intentions in mind. But it allows now to do something like this:

This makes it possible to use AutoIt’s methods directly through RAutomation’s AutoIt adapter.

Use AutoIt Only Where Really Needed

It would be ideal if you’d just convert all the existing AutoIt code to use RAutomation. Trust me, it would make sense to even you after you’ve changed your code - it’s cleaner, more readable and better in any way. Just refer to RAutomation’s README and this blog post and you’re set to go. If you’re familiar with the syntax of Watir itself then RAutomation’s syntax should be quite easy to follow also since it is inspired by Watir.

If there are still some places where you really-really need to use AutoIt due to some missing feature in RAutomation itself (don’t forget to tell me about it through GitHub issues!) then you can use AutoIt adapter also per RAutomation object and not globally by using environment variable like this:

RAutomation::Window.new(:title => /Internet Explorer/).adapter # => defaults to :win_ffi RAutomation::Window.new(:title => /Internet Explorer/, :adapter => :autoit).adapter # => uses :autoit for this object

This makes it possible for you to use AutoIt’s adapter in only places necessary.

Overview Of Upgrading Steps

If you don’t have any custom code using AutoIt then upgrading to Watir 1.9.0 shouldn’t cause you any problems - internally RAutomation is used and you shouldn’t even notice it. But if you have, then i recommend following the steps below to make the upgrade less painful:

set RAutomation to use AutoIt globally via environment variable
replace usages of Watir.autoit with browser.rautomation
replace in small steps your AutoIt code to use RAutomation
use :adapter => :autoit option for RAutomation to use AutoIt in very specific places where using RAutomation’s default adapter is impossible
remove the environment variable to use RAutomation’s default adapter
profit!

Conclusion

I think that using RAutomation instead of AutoIt is a good move. I’ve had that idea for a longer period of time and that’s one of the reasons i created RAutomation in the first place. Thanks to Hugh McGowan for implementing this idea. Viva la RAutomation!

WatirSplash With Different Browsers

Tue, 01 Mar 2011 10:00:07 +0200

WatirSplash supported only Windows operating system and IE browser to perform browser based user interface testing. The reason behind that restriction was the usage of Watir framework, which by design is Windows-specific and controls Internet Explorer. Using that browser to test is usually great because most of the developers (including myself) are not using IE during their development time and it is also the most error-prone browser. This all means that it’s good to run your tests with the IE since it has the highest probability to find some bugs during the creation of the tests and in the future.

Gimme More!

Starting from WatirSplash version 1.1.0 it is now possible to run tests in Linux and OS X by using Firefox and Chrome browsers. This functionality is provided by using other frameworks in addition to Watir itself - FireWatir and Watir-WebDriver. WatirSplash allows easy switching between the frameworks and browsers.

Switching the Frameworks

It is possible to switch the framework by using environment variable or by just specifying the framework in the code.

All possible values for different frameworks and browsers are currently the following:

watir
firewatir
watir-webdriver/ie
watir-webdriver/firefox
watir-webdriver/chrome

Use environment variable called WATIRSPLASH_FRAMEWORK to specify the current framework:

This makes your WatirSplash project tests to use Watir-WebDriver framework with Firefox browser. Pretty straight-forward.

As written above then it is also possible to specify the used framework directly in the code. It is meant to be done in your config.rb file under the ui-test and/or ui-test-common directories. If you specify it in the ui-test-common directory then the ui-test directory has higher precedence and framework specified there will be used. On the other hand if you don’t have any frameworks specified in the ui-test directory then the framework specified in the ui-test-common directory will be used. The framework to be used can be specified like this:

This statement makes WatirSplash to use FireWatir framework with Firefox browser (obviously).

Framework specified by environment variable has always the highest precedence, then comes the ui-test’s and ui-test-common’s config.rb, in that order.

Default Frameworks

This additional functionality in WatirSplash is fully backwards compatible. If the framework is not specified anywhere then the default framework will be used. The default framework depends of the platform where the tests are ran. The default framework in Windows is Watir and in Linux/OS X it is FireWatir.

Possible Dangers

You have to keep in mind that switching the frameworks could cause some problems when running the tests due to the different incompatibilities between the frameworks. Watir and FireWatir, for example, are not 100% compatible with each other. Same goes for Watir and Watir-WebDriver. Also, i’d not consider Watir-WebDriver’s IE and Chrome drivers stable yet. The only driver i’d recommend to use from Watir-WebDriver would be Firefox’s.

Conclusion

There you have it - a quite flexible solution for all your browser testing needs. Just have some things in your mind while switching the frameworks and you’re good to go. There will be probably more supported frameworks added to WatirSplash in the future. Just keep an eye on the changelog.

Autotesting With Doom-Guy

Thu, 06 Jan 2011 22:49:05 +0200

This post is inspired by one of the over-3-year-old-posts about using Autotest with Growl to show nice notifications about passing and failing tests.

Doom-Guy is here!

I’ve created a small gem for you to get the same helper for your testing needs. It is called autotest-doom which works with RSpec. Read below for installation and configuration instructions.

This is how it looks under Windows when everything is green and Doom-Guy is happy:

He looks a little bit hesitant, if something has failed:

It looks like his day has gotten even worse:

I’d say that there is definitely some visible blood when you’re having this many failures:

You’d better get yourself together and fix those failing tests now or he’s going to die!

And he’s dead… Do you really want to be such a lousy software developer?

Maybe, just maybe, if you’ll fix all the tests he will be alive again and you’ll be a lifesaver. Wouldn’t that just feel awesome?

Installation & Configuration

In today’s Ruby world things are a little different compared with the previously mentioned old post. My approach is to support not just OS X, but also Windows and Linux. It is possible via help of Test Notifier gem, which has created a clean API by using abstraction layer for using different tools to show notifications. It uses Growl under OS X, Libnotify among many others under Linux and Snarl under Windows.

The following instructions are for Windows, but they’re really similar to other OS-es too. Just refer to Notifier’s documentation about installing correct notifier tool for your OS and you’re ready to go.

Download Snarl from it’s website and install it.
Install ruby-snarl and test-notifier gems:
gem install ruby-snarl test_notifier
Install autotest and autotest-doom gems:
gem install autotest autotest-doom
Create .autotest file into your project’s root directory with the following contents:
require "autotest/doom"
And start testing!

That’s it! Make sure that you’re not killing that poor old Doom-Guy too often and everyone is happy!

Win32-Screenshot - From Cradle To ...

Wed, 22 Dec 2010 22:28:00 +0200

Win32-Screenshot is a library in Ruby for capturing screenshots on the Windows operating system. In this post i’m gonna write about the history of this gem since it just made it to the version 1.0.0 and i find that it deserves some extra attention due to the changes it has gone through.

Pre-Historic Times

The gem was originally created by Aslak Hellesøy, now a lead developer of the popular BDD library called Cucumber. Let’s see when was the first commit made to the Win32-Screenshot project by him:

C:\win32screenshot>git log --format=medium | tail -n 5
commit bd172fcc53c9a5a2dc96d5c8b71a2595fb16741b
Author: Aslak Hellesøy 
Date:   Wed Nov 29 17:27:13 2006 +0000

    Importing

It’s over 4 years old! Deciding of the commit message “Importing”, i’d say that the project started even sooner and got imported to the Git versioning system like this. Too bad that git-svn or something similar was not used to prevent losing the earlier history. The version of the library was at the time 0.0.1. Rails was already rocking with the version of 1.1.6.

Final Publicity

When browsing Git history it’s possible to determine that version 0.0.2 got ready at the 2nd Dec of 2006 and ended up also as a gem on RubyGems. The API was quite simplistic, but also limited:

# takes a screenshot of the foreground width, height, bmp = Win32::Screenshot.foreground # takes a screenshot of the desktop width, height, bmp = Win32::Screenshot.desktop # takes a screenshot of the window having "Firefox" as part of it's title width, height, bmp = Win32::Screenshot.window(/Firefox/) # saves the last bitmap to the file File.open("c:/images/firefox.bmp", "wb") {|io| io.write(bmp)}

There was only three simple methods part of the public API - #foreground, #desktop and #window. All of them returned an array of three elements - width, height and bmp. First two represented obviously width and height of the taken screenshot. Last one, bmp, was a blob of the bitmap in string format, which allowed it to be written into file by using Ruby’s File class like demonstrated above.

Inconveniencies

If we’re to think about the problems of that version’s API, then the main one for me was that three-element array returned from the methods. I wanted to use mostly one of the returned variables and it was obviously the one representing bitmap blob. So i had to do something like this:

# just ignore width and height variables width, height, bmp = Win32::Screenshot.foreground File.open("c:/images/foreground.bmp", "wb") {|io| io.write(bmp)} # ignore them even more by using special variable names _, _, bmp = Win32::Screenshot.foreground File.open("c:/images/foreground.bmp", "wb") {|io| io.write(bmp)} # just use the Array#[] with index result = Win32::Screenshot.foreground File.open("c:/images/foreground.bmp", "wb") {|io| io.write(result[2])} # or use the Array#last method result = Win32::Screenshot.foreground File.open("c:/images/foreground.bmp", "wb") {|io| io.write(result.last)}

I didn’t like any of the tricks above. Ruby is meant to be beautiful and this was just not it.

Usability Limitations

The limitations of the API might have not been so obvious, but i’m sure that eventually anyone who was using it, stumbled onto them. There was nothing wrong with the methods #foreground and #desktop since they did what you’d like them to do and there was no way that you’d like them to do anything else (well, maybe you’d have liked the #desktop to take a screenshot of the actual Windows Desktop and not from the entire visible screen, but that is just the functionality of the Windows API itself).

The #window method on the other hand supported only searching Windows with a regular expression so if you wanted to take a screenshot of some window with an exact title you had to use something like /^exact title$/. And you couldn’t do much if you had multiple windows with the exact same title since it was the only thing by which you could search by. Maybe you got lucky and got the correct window each time. Maybe you didn’t.

There were an internal methods called #get_hwnd and #capture_hwnd which allowed you to get the handle of the window and take a screenshot of it. The only problem was that #get_hwnd allowed to search for windows only by the regular expression of the title like #window did. If you got the handle to your window from somewhere else then you didn’t have any problems of capturing the correct window. Lucky you.

Technical Limitations

The main technical limitation of the Win32-Screenshot 0.0.2 was that it was using Windows API via Ruby/DL. The problem with that is the fact that DL is part of the Ruby standard libraries and isn’t compatible between different Ruby versions which automatically meant that Win32-Screenshot was not usable between different versions of Ruby either. There were also occasional segmentation faults happening caused by the DL.

Other big technical limitation was the need to use the RMagick gem to save screenshots into some other formats than big file-sized bitmap (bmp). If you’ve used RMagick on Windows then you ought to know that the installation of it can be quite painful.

Allow me to fill you in with the details in case you’re not aware of the complexity of that procedure. You have to install ImageMagick. And not any version will do, but you have to install very specific version of ImageMagick to make your experience a little more pleasant. You can get the specific version from the RMagick website. The provided 24 MB compressed file includes also the gem for that specific version which you can install with usual `gem install` command.

This all works as long as you’re using Ruby 1.8.x MRI version. As soon as you’d like to start using 1.9.x, you’re pretty much on your own. You have to compile RMagick gem for yourself. You ought to know that this is not an easy task under Windows. Yes, you can do it with the help of DevKit, but it’s still quite far of the simplest thing you’ll do within the day or two.

Imagine how hard it is to start using Win32-Screenshot gem with the full potential if every new user has to complete that process manually instead of just executing `gem install win32screenshot`.

In addition to the problems above the version 0.0.2 had also a little bug, which made capturing screenshots fail when they were at certain sizes.

Birthday Party Which Got Cancelled?

I have considered the possibility that most of the problems described above didn’t have any easy solutions at that time due to the missing libraries/tools which exist today, but the biggest problem was that all of these problems existed until May of 2010 when i started to clean it up. I guess Aslak just moved on to other platforms like OS X and didn’t have the time nor will to make it any better.

When browsing more of the Git history then there is one interesting commit:

C:\win32screenshot>git log --format=medium c8e6f9 | head -n 5
commit c8e6f9e20b957e52d1ddf5d5e0416f7f04d7b12b
Author: Aslak Hellesøy 
Date:   Thu Jan 18 18:36:15 2007 +0000

    Releasing 0.0.3

But when looking on the RubyGems then there isn’t version 0.0.3 anywhere to be found.

The only difference pretty much in that version was a small change in the API - instead of returning a three-element array, a block had to be used for all the methods:

I liked it at first, but now i’m thinking that it made the API even worse because there wasn’t even possibility to use Array#[] and Array#last methods anymore to avoid using variables for width and height. You just had to always declare those variables. It was like you had to pay your bills, but you had to do it much often. I’m pretty sure that you understand how uncomfortable that makes you feel.

Change Of Winds

If i recall correctly then i started using the library in the end of 2007. I didn’t know much about the Ruby at the time so i just used it. I noticed that sometimes screenshots capturing failed and other times segmentation fault greeted me with a big smile, but it didn’t happen too often. I was using the library occasionally during the period of two years before these things really started to bug me.

I started by looking for a newer version of the gem, but got disappointed since the last version was still 0.0.2. At least RubyGems told me so. Then i found out that there was offered a patch for the bug of erratic failures of capturing the screenshots. I forked the Win32-Screenshot project, applied the patch and made a pull request to Aslak. Aslak didn’t want to accept the pull request, but offered me to maintain the gem myself. I was surprised by that offer and took it. It was a right thing to do in terms of reviving Win32-Screenshot if i’m thinking about that now. Aslak could just have ignored my pull request and the things would be probably be the same today.

Surfing On The Code

That essentially meant i could do whatever i liked with the library. I’ve added the patch for the bug which caused screenshot capturing to fail and started with replacing fragile Test-Unit tests with more robust RSpec specs.

Next step was to replace Ruby/DL with something else due to these segmentation faults. I didn’t think at first that there would be any problems when using win32-api gem. All usages of Ruby/DL got replaced one by one with win32-api until i realized that if i’d like to use Ruby 1.9 then this solution wouldn’t work either, since there wasn’t any pre-built win32-api gem for these versions of Ruby. At this point i discovered the wonderful ruby-ffi gem which also promised to give me support for JRuby. What a bargain! Again, all usages of win32-api got replaced with ruby-ffi and a support for all MRI versions of Ruby and JRuby was achieved.

I started to like how the code was turning more beautiful with each day and released version 0.0.4 on May 26, 2010. This version addressed those three critical show stoppers - failure of capturing screenshots, segmentation faults and compatibility with different Ruby versions. It felt almost perfect. I called it as “A Complete Overhaul”.

Highway To Better

After the release of version 0.0.4 i started to polish the code and add some additional methods to the API like #window_area and it’s friends, which allowed to capture an area of the window specified by the coordinates. Also, exact window title could now be used by specifying string instead of a regular expression. I got also some contributions from Roger Pack. I always love contributions, thank you!

From that point forward new versions were released quite often, until 0.0.8. At that moment the API was more or less the same as it was in 0.0.3 (the need to use blocks was still there), but just more methods were in the arsenal. Even methods which didn’t make anymore sense to have in the context of “capturing a screenshot”. For example there were some utility methods like #all_desktop_windows and #window_process_id, which just didn’t seem to fit in my mind in that gem.

Cleaning Leaves

That’s when i realized that i wanted to do a completely separate library for searching and retrieving information about the windows. I started development of RAutomation. I’ve written about that library in my previous post “Automating Windows and Their Controls With Ruby”.

Extermination Of Bad Bacteria

As written above then the bad dependencies for Win32-Screenshot included ImageMagick and RMagick. I tried to find a way to remove the need for dependencies which need to be installed separately of the gem. My research for possible options ended up with an unfortunate news that there just wasn’t any fast enough solutions to save files to PNG format with pure Ruby. The next best idea was to use MiniMagick, which is a Ruby library wrapping ImageMagick’s executables for image manipulation and saving to different formats. So if i could bundle all necessary ImageMagick’s libraries and binaries with the gem i’d be on the road.

You know what? I managed to do it! Starting from version 1.0.0 all necessary parts of ImageMagick are bundled with the gem which means that you don’t have to have ImageMagick nor RMagick installed to save screenshots into BMP, GIF, JPG or PNG formats with Win32-Screenshot! Now you just have to have Ruby installed and you can just execute `gem install win32screenshot` and not worry about anything else. Awesome, isn’t it?

The New Beginning

Removal of dependencies ImageMagick and RMagick made me think that maybe, just maybe, i could make Win32-Screenshot even better.

Creation of RAutomation allowed me to delete a lot of code from Win32-Screenshot. For example i was able to delete all the code related with searching the windows - “Capturing screenshots functionality shouldn’t know anything about how to find windows”, i thought. All that code, in better form of course, ended up in RAutomation. I just had to set RAutomation as a Win32-Screenshot’s dependency and start using it in the code.

By using RAutomation i got this idea of changing the API of Win32-Screenshot quite drastically to make it better, but of course break backwards compatibility as a side-effect. I started to tinker the code by trying out different ways of how the new API could look like. The result i came up with has only one method in the public API which parameters decide what to take screenshot of and an Image class which holds the bitmap data with allowing to save it to the disk. Check out the following examples:

# Take a screenshot of the window with the specified title Win32::Screenshot::Take.of(:window, :title => "Windows Internet Explorer").write("image.bmp") # Take a screenshot of the foreground Win32::Screenshot::Take.of(:foreground).write("image.png") # Take a screenshot of the specified window's top-left corner's area Win32::Screenshot::Take.of(:window, :title => /internet/i, :area => [10, 10, 20, 20]).write("image.jpg") # Take a screenshot of the window with the specified handle Win32::Screenshot::Take.of(:window, :hwnd => 123456).write("image.gif") # Take a screenshot of the child window with the specified internal class name Win32::Screenshot::Take.of(:window, :rautomation => RAutomation::Window.new(:hwnd => 123456). child(:class => "Internet Explorer_Server")).write("image.png") # Use the Image for something else than #write image = Win32::Screenshot::Take.of(:window, :hwnd => 123456) image.height # => height of the image image.width # => width of the image image.bitmap # => bitmap blob

The integration with RAutomation allows to use the same nice API for specifying what window to take a screenshot of. I’ve also made it possible to give a RAutomation window object directly as a parameter to make it all even more flexible without the need to add much complexity to the Win32-Screenshot’s own code. Also, the #write method used in the examples above works as you might expect - if you specify the image file extension as a “.png” then it will be saved into the PNG format. No need to specify anywhere explicitly that you really want it to be saved as a PNG format and not just with an extension of “.png”.

From Cradle to Adulthood

There is this other popular saying called “From Cradle To Grave”, but this post is not about that at all even if the title might have suggested it. This is about a birth and it’s journey to it’s adulthood of Win32-Screenshot. It made it to the version of 1.0.0 on December 16th of 2010. Since it is now following “Semantic Versioning” rules then i felt increasing the major version number due to the backwards incompatibility changes to it’s API. Also there’s a statement on the “Semantic Versioning” guidelines which just made it great to increase the version: “Version 1.0.0 defines the public API”. I’m declaring to the world that this is the public API and i’m really happy with the results code-wise and API-wise.

Thank you, Aslak for making it all possible! Happy holidays with screenshottin’ and don’t hesitate to give me any feedback!

One last thing - guess what happens if the following code is executed right now on my machine:

Of course glimpse of The Awesomeness will be saved to my disk with The Awesomeness itself. It’s almost as scary as running VM inside of another VM!

Automating Windows and Their Controls With Ruby

Sat, 18 Dec 2010 01:07:00 +0200

Update: added part about handling popups.

How would you automate windows and their controls like button and text fields if you had to? How would you do that in Ruby? I guess you wouldn’t. At least not in any user-friendly way.

Until now. I’ve created a Ruby library called RAutomation which allows you to control windows, retrieve different kind of information about them, fill text fields with desired jargon and click the buttons on them! That’s all via very user friendly API.

Let’s Start to RAutomate

For example, let’s fire up Internet Explorer so that it has File Save As dialog opened like seen on the picture below:

Now, let’s install RAutomation gem and start up an irb session so we can have our fun with that window:

C:\Users\jarmo>gem install rautomation Successfully installed rautomation-0.2.1 1 gem installed C:\Users\jarmo>irb require "rautomation" => true window = RAutomation::Window.new :title => "File Download" => #<:window:0x359268>"File Download"}>, @adapter=:ffi> window.title => "File Download" window.exists? => true window.visible? => true window.hwnd => 30345632

If you’ve used browser automation tool called Watir before then the code above should seem awful lot similar. The thing is that RAutomation’s API is inspired by Watir’s clean and nice API. Awesome news, isn’t it?

You can also see that i’ve managed to find the window, made sure that it has a title, that it exists, is visible and has a window handle (hwnd). Nice.

Clicking the Button

Ok, let’s click the Save button because that’s what i want to do, right? I want to download RAutomation’s gem from the RubyGems website! That would sound just odd if i wouldn’t. Clickety, click…

Whoops. That was almost as easy as walking in the park. The following window appears to make sure that i really want to download the file and i really know where to put it:

Filling the Fields

If we’ve already come so far then what choice do we even have anymore? I guess we have to tell it where to save the file. Let’s do it!

new_window = RAutomation::Window.new :title => /save/i => #<:window:0x5730f90>/save/i}>, @adapter=:ffi> new_window.title => "Save As" edit_field = new_window.text_field :class => "Edit" => #<:textfield:0x56c19d8>/save/i}>, @locators={:class=>"Edit"}, @text_field=#<:adapter::ffi::textfield:0x56c1990>/save/i}>, @locators={:class=>"Edit"}>> edit_field.exists? => true edit_field.value => "rautomation-0.2.1.gem" edit_field.set "c:\\users\\jarmo\\rautomation-0.2.1.gem" => true edit_field.value => "c:\\users\\jarmo\\rautomation-0.2.1.gem"

Saving The File?

It’s also possible to search windows by regular expressions? Nice! Ok, let’s click now that final Save button. Oh, dang. I just realised that i already have this nice gem because i installed it with `gem install rautomation` early on. It would be just plain stupidity to download it again, especially like this. I guess i’ll just ditch the window instead and carry on with the knowledge of having this wonderful library already in my posession.

What About Popups?

Let’s pretend that after you closed the window above, the following threatening JavaScript popup appeared out of nowhere:

First of all, if you’re using Watir then make sure that you’re testing your page correctly. If that’s not the case, then by all means, take risks in your life once in a while and close that popup:

Where’s The Catch?

The catch is that not all kind of windows and platforms are supported. Yet. Currently only Windows operating system and windows using Windows’ native components are (fully) supported. But why did i emphasize on the “Yet”? That’s because RAutomation is built to allow cross-platform compatibility with easy extensibility by allowing to support all kind of different technologies. This is where the Adapter comes into the play.

What’s an Adapter?

RAutomation’s adapter is a technical component of the library being responsible for dealing with controlling windows and their controls on a specific operating system for specific technologies. As stated above then currently only Windows operating system is supported with two different adapters - :ffi and :autoit. By default :ffi adapter is used on Windows to execute Windows’ API functions directly. If there’s any need to change the adapter then it’s possible to specify another default one by using an environment variable called RAUTOMATION_ADAPTER or specifying different adapter for controlling specific window with the :adapter option:

C:\Users\jarmo>set RAUTOMATION_ADAPTER=autoit ie_autoit = RAutomation::Window.new :title => /internet explorer/i => #<:window:0x480c000 explorer>, @adapter=:autoit> ie_autoit.hwnd => 18155218 ie_ffi = RAutomation::Window.new :hwnd => 18155218, :adapter => :ffi => #<:window:0x59fd2d0 :hwnd="">18155218}>, @adapter=:ffi> ie_ffi.hwnd => 18155218

Since i’ve set the environment variable to autoit then the first window is using adapter for AutoIt. The second one uses FFI instead since i specified it with an :adapter option. And of course they both point to the same physical Internet Explorer window.

How to Create New Adapters?

Since i’ve built RAutomation having all kinds of different platforms and technologies in mind, i’ve created a possibility to extend it relatively easily. If it’s possible to automate windows with Ruby directly or with the help of some external tools on the platform, then it should be possible to create a new Adapter for RAutomation. Just follow the steps below. I’d be happy to merge the results into the master.

Fork the project at GitHub
Create entry point file to lib/rautomation/adapter which should load all adapter specific files
Add `autoload` statement into lib/rautomation/adapter/helper.rb for that file
Create a directory for your adapter’s specific code into lib/rautomation/adapter
Copy button.rb, text_field.rb and window.rb from some of the existing adapter’s directory
Add spec data for your adapter into spec/spec_helper DATA constant
Use environment variable RAUTOMATION_ADAPTER to point to that adapter
Start coding and spec-ing until as much of possible of the public API is satisfied
Make me a pull request

Until then, have fun with the existing adapters!