RubyTester Blog

Research on Usecase and Userstories

2009-08-24T10:35:44-05:00

DRAFT

To distinguish ‘Simulation’ from ‘Verification’ strategies in acceptance testing code.

I chanced upon a compendium of XP 2004 papers and there I’ve found a paper by Johan Andersson and Geoff Bache Adventures in GUI Acceptance Testing I love the concept of ‘simulation’ and ‘verification’ as two different strategies. ‘Simulation’ is all about driving the GUI and ‘verification’ is all about assertions.

This is how I have been structuring my GUI Acceptance Testing with Watir. I refactor all the code that ‘simulates’ user’s scenarios into code I call UseCase and then I write test code (Rspec or TestUnit) code that is responsible for ‘verification’. This separation allows me to drive GUI to setup context in which ‘checking’ and ‘verification’ occurs. Since my usecase is a model driven by examples (notetoself: find article on Model → Example → Model feedback cycle to refine model by examples).

Unfortunately that XP 2004 paper is “behind the moneywall” on Springer but you can find the docs here (and here is a googlebook text)
In XP 2005 they continue with Further Adventures in Acceptance Testing talking about xUseCase).

The concepts from these guys are interesting. It seems I have been doing something similar in my acceptance testing approach and it is really great to read some feedback on such an approach.

The main idea I see here is the distinction between Usage Simulation code and Test Verification code. The Usage Simulation code is written in a customer’s language, a domain language customer operates to produce results in that domain.

Usage-First design strategy

There is this nice strategy for writing code from TDD. You “write the code you wish you had”, you pretend that it’s there, you write how a client uses something, and then you write that something. This is how I write UseCase scenarios in code. It’s in a style of Red, Green, Refactor.

Very important point. UPDATE: Bret Pettichord mentioned at LSRC that we could call this “Subject Oriented Development”. I am not sure how that fits but again, important point becuase in BDD we are designing behaviour of objects but in Subject Oriented Development you design system behaving according to the Subject. (more on that at some point)

OK, so a couple of quotes from the those guys’ papers.

Acceptance Tests are entirely independent of design, because they do not interact with it. This means they form a solid rock to lean on when doing refactoring (of the design, emp. added)

Unit Test is a design statement. Acceptance Test is a statement of a correct behaviour of the system. Unit Tests act as design documentation, acceptance tests document system behaviour. (paraphrased)

Why UseCase and not a UserStory

Read Mike Cohn’s paper on Advantages of User Stories for Requirements October 2004 published in InformIT Network

He explains how UserStories differ from UseCases. My takeaway is UserStories are used in BDD but I would use UseCases in Subject Oriented Testing becuase it follows Example > Model > Example cycle and has persistence of End to End goal seeking.

These are some good distinctions I think. Any feedback?

Moving to Vim on Windows and Ubuntu

2009-09-13T16:03:35-05:00

Getting to know Vim. Nobody has ever told me how simple it is.

The first person I’ve ever met who uses vim was Charley Baker. He actually showed me Vim running on his Mac at AWTA2009 in Austin.
It’s funny that as a tester working with developers for many years I have never met anyone working with Vim and most of the ‘reputation’ I hear about vim is that ’it’s very hard’ to learn to ‘understand’ it and to learn to ‘operate’ it.

So I asked some questions and poked around and found out it’s not so hard. It is a great editor for a tester. It seems there is no ‘magic’. There is only ‘practice’ just like everthing else. Well, easier said than done of course.

I am writing this in ‘Gvim’ on Ubuntu (vim-genome package, no sure what the diff is with gtk package). I set up ‘Gvim’ also on my WinXP machine. The first thing conceptually I had to understand was the Vim is a ‘tool for working with text’ environment, you ‘operate’ on text in vim. It’s kind of nice that vim is all about making ‘you operate’ on text, I mean really ‘you’. I am just starting to learn. The two things to understand are config files _vimrc, _gvimrc and vimfiles on windows and for ubutntu the .vim dir and .vimrc, .gvimrc files. They are mostly the same. (FYI plenty of resources on github)

Gvim on Windows

I downloaded Gvim on Windows and installed it into c:\Programs\vim. In Windows the ‘~’ home dir is USERPROFILE so that’s where I put my ‘_vimrc’ and ‘_gvimrc’. The _gvimrc file is read by gvim only, not by vim (correct?). If I want to use vim in a commandline I would not need _gvimrc (still learnig on this one). The next thing was to create ~/vimfiles/colors/ and put in there a herald.vim file. Nice colorscheme. There are more. Many many more.

On Ubuntu the similar thing was to create some settings in ~/.vimrc and ~/.gvimrc which are equivalent to _vimrc and _gvimrc on windows and ~/vim/ directory where you keep colors and plugins; equivalent to ~/vimfiles on windows.

Gvim out of the box is ugly, maybe this is why most people give up on it in the first few minutes. I use Bitstream Vera Sans Mono font. (been using this font for ever it seems).

I think I am on my way to give up notepad++, jedit, scite and stick with vim. I am glad I’ve just decided to take a day and poke around to see if I can ‘get vim’ on my own. But really I am quite surprised that nobody has showed me ‘vim’ before.

As to IDE I am sticking with Netbeans for now but for all text stuff I am looking forward to learning more ‘vim’ hacks.

P.S. Well, this post is a bit lame. I am just practicing on vim here.

some para text

Watir Semantic Shortcuts to Elements

2009-07-29T09:28:29-05:00

Accessing Watir elements with semantic shortcuts

UPDATE: remove module_eval wrapper from self.face method in the last example. it was not needed.

Let’s say you have a text_field element named “last_name” you want to access on a page and the text_field is inside a div container with id ‘person’. You may write something like this in Watir API:

browser.div(:id, 'person').text_field(:name, 'last_name')
# or something like this if you don't care about text_field contained by the div
browser.text_field(:name, 'last_name')
# but for our purpose we'll stick with the div containing text_field scenario

And what if you want to decouple the GUI specific implementation and replace it with a shortcut that refers to that text_field element? After all when user is visiting a page she does not fill the text_field with a :name, ‘last_name’ or ‘lst_nme’ or ‘lnm’ . She enters her ‘last name’ on the ‘page’. So you can call that page object last_name (in Ruby speak). Then you would need to provide some kind of translation between the page object name and the DOM name. But why even bother with that? There are at least 2 payoffs; 1) you write tests that in a language users speak which brings clarity and intention revealing behavior and 2) over time maintanance is minimized; contained to the methods that define page elements and not to our tests.

How to build the accessors to dom elements

The simplest way to decouple GUI from your tests is to wrap the code that accesses the DOM element with a friendly domain specific name.

def last_name
  browser.div(:id, 'person').text_field(:name, 'last_name')
end
# and call it with last_name method
last_name.set "Johnson"

But if you have 10 or 20 or 100 of those elements there has to be a better way. You can define a dynamic method that creates the wrapper methods for you. Maybe like this.

access_to :last_name do
  browser.div(:id, 'person').text_field(:name, 'last_name')
end

The access_to method defines last_name method or any other method for you. (on that later). As you can see there is not much difference between the def wrapper method and the dynamic generator. However in a dynamic generator you can set the receiver of the block, maybe access logging and provide call back methods or some other special code. The dynamic generator is your factory of shortcuts to elements.

For example one of the things you can take care of in dynamic method creation is to provide the browser as the receiver of the block, then you shorten your definition:

# browser as receiver will be provided for you
# notice the browser method is not referenced here
access_to(:last_name) { text_field(:name, 'last_name') }

This dynamic method generation mechanism is used by many Watir libraries (see Taza element and Watircraft field and Watirloo face methods, or Rasta keyword). It allows you to create a semantic page object name, keyword, simply a friendly name to access an element on a page. The semantic names conform to the way a user would talk about objects on the page so their names are customer facing and are used to describe tests. The method definitions are developer facing and they wire the semantic name to an element in the DOM. This is a kind of a facade or adapter mechanism (Look up Design Patterns Facade and Adapter) And again the benefits are test clarity and minimized maintenance.

If you still wonder how this may work here is a scenario example: imagine you have many tests that use the call to last_name but at some point the text_field definition changes, maybe a :name attribute is changed or it’s not a text_field any more, maybe a select_list of last names. Now you don’t have to go and find all the instances of a text_field(:name, “last_name”). All you have to do is update the definition stored by the facade method rather than in all the places the text_field is used as implementation. In this case the last_name method is used as a ‘stand in’ for that text_field or select_list or whatever elemtn. The last_name is a facade method, a face to interact with.

Page Object as a shortcut to a collection of elements.

What if you have two text_fields on a page like this.

text_field(:name, 'last_name0')
text_field(:name, 'last_name1')

Now the page is asking to fill the last name for two people. Are you going to have to define the last_name0 and last_name1 access_to method? No, we can treat the text_fields sharing similar naming pattern as a collection.

We can maybe do something like this

access_to :last_name do |nbr|
  text_field(:name, "last_name#{nbr}" #pass the counter to alter name attribute
end

# and then you can access 
last_name(1).set "Johnson"
last_name(2).set "Kowalski"
last_name(42).set "Adams"

This is an example of how an access_to type method can be made to accept attributes that then alter the pattern of access in a collection.

Watirloo with face method for making semantic page objects

In Watirloo I call the method that creates semantic page objects the face method because it helps to make an interface to some element on the page and face is a sort of a facade, and invokes some semantic personalization. It’s fun to write tests where you define faces you talk to in your tests.

Here are some examples of how you create faces in watirloo that map to some cryptic DOM definitions for address form

face(:zip) { text_field(:name, 'zipCd')}
face(:street) { text_field(:id, 'adrStr1'}
face(:state) { select_list(:name, 'stCd'}
# now you can call them in your test
zip.set "75230"
street.set "Walnut Street"
state.set "TX"

What I haven’t mentioned is how the face method defines a receiver of the block given by a facename. When you call zip or street method who receives the call? Well the current ‘self’ receives the call, it can be rspec group or TestCase class or any other object that contains the face definition. But who receives the call of the body of the method? Here is an example where browser is the receiver of the block

# defines access to element based on its facename
def face(facename, *args, &block)
  define_method(facename) do |*args|
    browser.instance_exec(*args, &block)
  end
end

The main part is browser.instance_exec It’s just like instance_eval but accepts arguments passed to it (as seen in the last_name(1) example).

In the above face definition I assume that all interfaces talk to the browser directly as the page container. browser is the receiver of the blocks defined by face method and here implicitly provided by the face method. If it wasn’t then we would need to provide it somehow in the definition.

Here are two different examples:

# browser as receiver assumed implicitly and provided by face method
face(:person) { div(:id, 'person') }

# browser provided explicitly. The face method assumes the browser method exists in the receiver
face(:person) { browser.div(:id, 'person') }

Which is better? Not sure, I think I’ll go with the first choice for Watirloo face definition treating the browser (or the root document if frames are present) as implicit receiver for facename blocks.

Shifting receiver with chaining.

But what if you want to specify that the text_field is inside a form or a div and you want to provide a specific access to that particular location. Maybe you would like to write you tests with that containment in mind:

# instead of 
browser.div(:id, 'person').text_field(:name, 'last_name0')

# you wish you could write like this shortcut
browser.person.last_name(0)

# and you imagine these definitions that would support it
face(:person) {div(:id, 'person')}
face(:last) { |nbr| text_field(:name, "last_name#{nbr}")}

# but that will NOT WORK out of the box

Will not work! No! No! No! Well, maybe… but it requires some manipulation of ‘self’ of the returning objects as you chain them.

The Watir API is beautiful in this regard. The ‘div’ method returns the reference to DOM where the ‘div’ is located and you can call the text_field on it so the locator will find that element contained in the ‘div’.

The secret in Watir code is something like the factory methods used.

def text_field(how, what)
  TextField.new(self, how, what)
end

This really is the genius of Watir API design IMHO because text_field method instantiates TextField class and passes it the context of a container. Then the TextField calls set_container to narrow the scope. Very nice indeed.

The problem with page objects chaining is that we need to manage the scope of containment. Simply doing the chaining because it looks nice and convenient browser.person.last_name(0) will not work unless the call to ‘person’ method returns the receiver that also has last() method defined. If you are lost at this point don’t worry and read on.

In Watir API browser returns an object that responds to methods like ‘div’ or ‘text_field’ and in turn the ‘div’ method returns an object that responds to ‘div’ or ‘text_field’ methods as well. With each method you ‘chain’ you narrow the scope of the DOM tree where a particular element is contained. Watir element methods take care of establishing the receiver implicitly. That’s what makes Watir API so nice. Pleasing to use and hard working behind the scenes.

I may be exaggerating a bit but this is why I think Watir is underappreciated in Ruby community because it mainly targets Windows and Internet Explorer but that is precisely the reason why Watir is still ‘undiscovered’ in the Enterprise browser testing where high cost commercial solutions win because of marketing.

Back to our topic: In building some kind of a abstraction layer that decouples implementation from page objects, known sometimes as GUI mapping, we would need to manage that scope in a face definition.

Which Solution to Implement?

Solution (1) is to define faces with known receiver as page the root element (either a browser or a frame) and forget the method chaining. Any facename like last_name method would be made to call on page but person.last chaining would not work because person returns Watir ‘div’ object which does not respond_to? last. So if you want fined grained control just drop to the Watir API and deal with DOM implementation that way. This is my preferred method (do not obscure Watir API, work with it, do not hide it).

Solution (2) is to allow for method chaining that always has to start with browser or frame, a page method that returns the root document to talk to. In this case we can have page.person.last or page.last where page is the receiver of defined page objects. Then if you want to drop to Watir API you can use browser.div(:id, 'person') as instead of page.person (this has some potential)

Here are some code acrobatics to accomplish this.

def self.face(facename, *args, &block)
  define_method(facename) do |*args|
    @container = @container.instance_exec(*args, &block)
    self #return receiver to chain to next page_object
  end
end

def page
  @container = browser
  self #chain to next page_object
end

# now having this you can define
face(:last_name) {|nbr| text_field(:name,"last_name#{nbr}")}
face(:first_name) {|nbr| text_field(:name,"first_name#{nbr}")}
face(:person) { div(:id, "personPanel") }

# and use in your client
page.person.first_name(2).set "Kurt"
page.person.last_name(2).set "Vonnegut"

# or

page.first_name(2).set "Kurt"
page.last_name(2).set "Vonnegut"

Now you can access last_name() explicitly contained by person or just contained by page which is equivalent to browser unless you want to redefine it to point to a frame.

The new issue with this is that every time you call a facename method it returns ‘self’ in order for chaining to work. So if you want to call .set “value” method you either have to provide an adapter or handle it with method_missing like this;

# adapter to call Watir Element set.
def set
  @container.set
end

def method_missing(method, *args)
  if @container.respond_to?(method)
    @container.send method, *args
  else
    raise "Something went wrong"
  end
end

Another solution (3) would be to have a factory method that returns Face.new(container, facename, *args, &block)) and encapuslate this setting of container in the similary way Watir works. (or maybe just add Face class subclassed from Watir::Element to get that management for free?)

Either solution depends on your page objects need. I can see that chaining solution can give me more flexibility in situation where there is a text_field with the same name in two or more different forms but it adds some mental acrobatics to build this.

On the other hand the page.instance_exec makes sure every element is anchored to the receiver the page defines and be happy with that. Well, we’ll see. If you have any ideas let me know. For now Watirloo defines the Solution 1 in gem 0.0.6. In gem 0.0.5 you had to provide the receiver yourself in face definitions.

Another wild idea is to provide plain hash with array for definitions face :facename => [watir_method, how , what] so you can store the definitions as data in some files and use module_eval on heredoc maybe another post for that.

Any feedback on which solution makes sense to you? Thanks.

My First Fake Post With Webby

2009-04-13T11:26:34-05:00

Welcome to Webby installation. This first post is in textile.

Running command webby-gen blog rubytester_blog creates a rubytester_blog directory with all the scaffolding necessary for the webby site. The content directory has only css/blueprint and there is no blog directory. At this point run webby with -T switch to see what tasks are available to move forward.

$ webby -T
webby autobuild          # Continuously build the website
webby blog:post          # Create a new blog post
webby build              # Build the website
webby clobber            # Delete the website
webby create:atom_feed   # Create a new atom_feed
webby deploy             # deploy the site to the webserver
webby deploy:rsync       # Deploy to the server using rsync
webby deploy:ssh         # Deploy to the server using ssh
webby rebuild            # Rebuild the website
webby validate           # Alias to validate:internal
webby validate:external  # Validate hyperlinks (include external sites)
webby validate:internal  # Validate hyperlinks (exclude external sites)

Let’s make this blog post.

Running the following command creates 3 files.

$ webby blog:post "my first fake post with webby"
content/blog/2009/04/13/my-first-fake-post-with-webby.txt
content/blog/2009/04/index.txt
content/blog/2009/index.txt

This blog post file. this month index.txt file and this year index file. OK, so far so good. I understand the basic pattern (I think)

The default content for this blog was taken from /templates/blog/post.erb the month index from month.erb and 2009/index.txt from year.erb

so let’s do webby build task to generate a site

Generated SITE

I will refer to the webby site as SITE. I think webby itself refers to it as SITE anyway.

So to view the new SITE statically I encounter a problem. All the css is broken because looking at layout/default.txt all the href begins with /css/bla/bla. I can fix it be changing it all to ../css/bla/bla or I can use the server provided by webby by running webby autobuild

Let’s do ‘autobuild’. It uses ‘directory_watcher’ to scan for changes and automatically builds your site for you when it encouters a fresh page. That is an awesome feature. I think I’ll stick with that. My local site is now available at http://localhost:4331/

Next problem to overcome is lack of site index file. I’ll build it next and display a lis of posts.

page meta

Before building a home page let’s take a look at the page meta. this page got created with the yaml section that holds metadata for the page. Now I wonder about options becuse I have seen keys like layout: index and dirty: true so I wonder where I can quickly find that info hm… dubi dam dam dubi dam… OK… Webby::Resources::MetaFile class has some mention of it. I see I can use tags outlines slides and other things. This will be worth exploring later. First I got to make some sensible layout and a index home page file.

building a home page

I have two choices I think here. I can make a /content/blog/index page which will become a site home page or just make a blog/index for blog home page. Let’s do a blog specific home page first to display the list of blog posts, all? just the latest few? Maybe have some summary with title link? ok…

This ruby incantation returns all the posts in blog direcotry sans all index.txt files that hold year and month indices.

posts = @pages.find(
  :all, 
  :in_directory => @page.dir, 
  :recursive => true, 
  :sort_by => "created_at", 
  :reverse => true){|p| p.path !~ /\/index\.txt$/}

Now I need to print out each page. Let’s use HAML for the index. It will force me to learn it.
…do do do… do some more… ok, done for now. the index is done to display the list of posts.
Let’s make another fake posts to see that the second post also gets created.

… let’s move to the second post then.

Radio and Checkbox Groups for Watir and Firewatir

2009-08-12T15:18:31-05:00

Accessing Radios and Checkboxes in Watir

Radio and Checkbox access is sometimes difficult because to access a particular control in ‘watir’ you need to know its ‘value’ attribute, what if you could access a group of radios or checkboxes instead by the ‘name’ attribute only no matter what the values are for each individual radios. So I wrote a radio_group and checkbox_group methods to simplify that access.

Let’s start with the typical ‘watir’ code for accessing individual radios and checkboxes:

# 3 radios in a group. 
browser.radio(:name, 'rname', 'rvalue1')
browser.radio(:name, 'rname', 'rvalue2')
browser.radio(:name, 'rname', 'rvalue3')

# 3 checkboxes in a group
browser.checkbox(:name, 'cbname', 'cbvalue1')
browser.checkbox(:name, 'cbname', 'cbvalue2')
browser.checkbox(:name, 'cbname', 'cbvalue2')

Each one of the radios or checkboxes you access individually. However if you look at radios as a group you can see that it behaves like a single select_list control; you select one and only one radio. Selection of one unselects the others. That makes sense to me.
Similar with checkboxes; as a group you can see that it behaves like multi select_list control; you select none, one or more items.

Watir radio_group and checkbox_group methods

Radios and Checkboxes form a control set, a group when they share the value of a ‘name’ attribute (contained by a form) so instead of accessing them individually like items in a select_list we can access them as a ‘radio_group’ using the ‘name’ attribute and bypassing the ‘value’ attribute. (peruse the HTML401 spec for more info on form elements and name attribute usage for identification)

Here is an example:

# access all radios as a group
browser.radio_group('rname')

#access all checkboxes as a group
browser.checkbox_group('cbname')

The client code is simplified. You access radios and checkboxes without knowing their individual ‘values’.

Examples:

browser.radio_group('rname').size # => 3
browser.radio_group('rname').values # => ['rvalue1', 'rvalue2', 'rvalue3']


browser.checkbox_group('cbname').size # => 3
browser.checkbox_group('cbname').values # => ['cbvalue1', 'cbvalue2', 'cbvalue3']

To accompany the radio_group method I’ve also added radio_groups method that returns collection of groups on a page; similar with checkbox_group and checkbox_groups.
Word of caution: If you have two forms on a page and each form has a group of radios and each group shares the same value for ‘name’ attributes we’ll run into a problem. Do you see which one? Yes, the radio_group will report both sets of radios in two separate forms as one group. First of all you shoud not do that in HTML but if you do you have to delimit containement and address radio_group from each form and not from the root document.
Anyway, have a look at all the code at in watirloo gem
Take a look at specs, they run for both IE and Firefox.

This is a very helpful extension to ‘watir’. It has saved me many hours of work.

Using Local Watir Code from Git With Local Gem

2009-08-12T14:04:51-05:00

Turning a path/to/some/dir into a gem with ‘local_gem’ gem

“The other day while actively developing a gem, I got tired of rake reinstalling it to test its effect in irb with some other gems. I wanted to use the edge version of my gem, version now.” – this is how Tagaholic aka @cldwalker introduces his local_gem

I usually work with some stuff I have checked out from git like Watir or Watirloo but when I change some code and I want to use it in my client code I would normally need to create a gem and install it. (what I mean by client code is some code that uses the library and references it as a gem)

This takes time. It’s faster to treat the source code for a gem as a gem itsefl without modifing the client code that uses it. This is what ‘local_gem’ gem provides. Here is a short writeup on how I use it with watir family libraries when I work on my client code and need to make some custom changes to the ‘watir’ code.

Working with ‘watir’ family gems.

I work with with watir gem source mostly with the IE version and modify it with some custom extensions. I also work with ‘watirloo’ gem for my development. These libs are my infrastructure for my client’s test code base.

Here is how my client code uses the gems (I hope this is similar to how you use it)

require 'watir'
require 'watir/ie' # for some IE specific code

Pretty straighforward. This begs a question: What do you actually require? The ‘watir’ project source code creates 3 separate gems ‘commonwatir’, ‘watir’ and ‘firewatir’. The ‘commonwatir’ gem orchestrates which other gem lib to load depending on your browser choice. So require ‘watir’ actually requires GEMPATH/commonwatir/lib/watir.rb file of ‘commonwatir’ gem – and when you say you want to work with the browser=‘ie’ then commonwatir requires GEMPATH/watir/lib/watir/ie.rb file of the ‘watir’ gem.

To illustrate this I have made a crude drawing of require ‘watir’ and ‘watir/ie’ on flickr

so if you want to make changes to some ‘watir’ gem or ‘firewatir’ gem you can go to the GEMPATH place and mess with it there which is not recommended or you can work on the source code from git but then you would need to create gem and install it again to test in our client code the changes you may want or….. you can use ‘local_gem’ gem

Working with ‘watir’ code locally using ‘local_gem’

I use ‘local_gem’ in its override mode to bypass the cycle of “change code>make gem>install gem>try your client code”. I shorten it to “change code>try your client code” like this

require 'local_gem'
require 'local_gem/override'

LocalGem.setup_config(nil) do |conf|
  conf.gems = {
    'watir' => [
      "C:/code/github/watir/commonwatir/lib",
      "C:/code/github/watir/watir/lib"
    ]
  }
end

require 'watir' # loads the C:/code/github/watir/commonwatir/lib/watir.rb
require 'watir/ie' # loads C:/code/github/watir/watir/lib/watir/ie.rb

Mystery solved. Now in my client code I don’t have to make any changes to how I require ‘watir’ and I can hack on the git repo of watir files checked out from github. (Try it yourself. Checkout ‘watir’ and make some changes and see them reflected immediately in your client code that uses ‘watir’ code)

As a helper now we can invent an env var switch ENV[‘LOCAL_GEM’] to turn on or off the overrides so I can run one test using the officially installed ‘gem’ or my ‘local_gem’ version.

For good measure I will throw in my watirloo gem there too and some other stuff.

Here is how my setup looks like

if ENV['LOCAL_GEM']
  require 'local_gem'
  require 'local_gem/override'

  LocalGem.setup_config(nil) do |conf|
    conf.gems = {
      'watir' => [
        "C:/code/github/watir/commonwatir/lib",
        "C:/code/github/watir/watir/lib"
      ],
      'firewatir' => 'c:/code/github/watir/firewatir/lib',
      'watirloo' => "C:/code/github/watirloo/lib",
      'watircraft' => [
        "C:/code/github/watircraft/lib",
        "C:/code/github/watircraft/bin"
      ]
    }
  end
end

# and in my client code I need to provide the env var
ENV['LOCAL_GEM'] = 'override'

That’s about it. Hope you find it useful and thanks to @cldwalker for hacking the ‘local_gem’

Second Webby Construction Post

2009-04-13T16:58:44-05:00

Where I continue setting up webby o my o my…

Layout

Got to change some layouts/default.txt text … do … do …doing

o my o my… blueprint.css. What is all this: column span-20 prepend-2 append-2 first last ?
Now I need to learn the layout shortucts and get the conceptual model what blueprint.css is and what it is for … ok just read some articles got it..
So now off to layout but I have only 10 more minutes to spend on this so forget layout. just make links work and that’s it.

Purpose

I noticed that I have a hard time with writing in html tools and all the online places like blogger or wordpress. It makes sense to me to put something in txt files as source and work at it for few days and then publish some thoughts. So this is not really a blog but a scrapbook of analysis of things I work on so I will remember them in the future.

Rss Feed setup

got to make the feed. put the feed in blog/feed/atom.txt and on the layouts/default.txt add the line:

<link 
  rel="alternate" 
  type="application/atom+xml" 
  title="Blog Rss Feed"
  href="http://rubytester.com/blog/feed/atom.xml">

Deploy

how does webby handle the magic of deploy? webby provides 2 tasks webby deploy:rsync and webby deploy:ssh. and a general deploy task that first builds the site and then calls deploy:rsync.

The tasks are defined in file GEM_HOME\webby-*\lib\webby\tasks\deploy.rake.

The rsync tasks calls sh "rsync bla bla usual" and ssh uses SshDirPublisher.new(who what were bla bla).upload

So first in Sitefile I have to provide some of the options that will be used by the deploy like SITE.user, SITE.host, etc…

SITE.user = "rubytester" #your ssh name to login to the server
SITE.host = "rubytester.com" 
SITE.remote_dir = "~/rubytester.com"

ok, I think that should work.

let’s deploy…. tupi dooo ba ddo dooo… o crap!! Accessing the site gives me 403 Forbidden error.
What happened? .. ok, ….all the files are 500 mode -r-x------ and they should be 644 no? and directories should be 755? yes? I think so.
Maybe since I am on windows and I deploy to linux I end up with some generic permission collision.
the rsync or ssh task on windows does not work? or is my server not setup correctly?

looking at why webby deploy fails for me

webby uses the following tasks for deploy

require 'rake/contrib/sshpublisher'

namespace :deploy do

  desc 'Deploy to the server using rsync'
  task :rsync do
    cmd = "rsync #{SITE.rsync_args.join(' ')} "
    cmd << "#{SITE.output_dir}/ #{SITE.user}@#{SITE.host}:#{SITE.remote_dir}"
    sh cmd
  end

  desc 'Deploy to the server using ssh'
  task :ssh do
    Rake::SshDirPublisher.new(
        "#{SITE.user}@#{SITE.host}", SITE.remote_dir, SITE.output_dir
    ).upload
  end

end  # deploy

# EOF

Since I provided the user and host the deploy worked but the permissions for files sent to the server were incorrect. I write on Windows XP the files on the server were given mode 700. ok, let’s delete all the files from the server and try again using ssh this time instead of rsync

zippy duda do… ok, all ssh got copied over and the mode of files and dirs is rwx------ so I get permission denied on serving those files. Damn. The problem must be on windows side or on my server.

OK, let’s try to copy files with WinSCP; guess what, all dirs get set to 755 and files to 644 as expected. So the problem seems to be cygwin rsycn or OpenSSH for win xp. What if I switched to Putty? hmm… will need to investigate it. For now deploy is broken for me, I have to do it manually with winscp, (I wonder if Robocopy or RichCopy might work in this situation)

Next task add disqus to the posts

Next I think I should have some comments with disqus probably. But wait. I only want comments for articles and not for all pages but currently all pages are using one layout ‘default.txt’ so I need to make articles use its own layout first and include the output back in the main default.txt (I think). So this article.txt should have a layout: article and layouts/article.txt should have a layout: default.txt or just none, I mean default is default yes?

ok let’s do layouts/article.txt and add a disqus code to it.

Running Ruby Files on Windows

2009-07-24T14:05:56-05:00

Invoking Ruby.exe on windows

If you look at c:\Ruby\bin you will find two sets of files. One with .bat extension and one without.
for example let’s take a look at those two

c:\Ruby\bin\rake and rake.bat

rake (without extension) looks like this:

#!C:/RUBY/bin/ruby.exe
#
# This file was generated by RubyGems.
#
# The application 'rake' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0"

if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
  version = $1
  ARGV.shift
end

gem 'rake', version
load 'rake'

and rake.bat looks like this

@ECHO OFF
IF NOT "%~f0" == "~f0" GOTO :WinNT
@"ruby.exe" "C:/RUBY/bin/rake" %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO :EOF
:WinNT
@"ruby.exe" "%~dpn0" %*

so what happens when you run rake from the command line? it uses the first line in a file #!C:/RUBY/bin/ruby.exe -ws as a directive to run this file using ruby.exe the -ws is for warnings and swtich parsing. Look for yourself when you run ruby -help and read the help on switches.

Everything else in that rake files is pure ruby code

The interesting file is the rake.bat. The %1 to %9 are arguments. %0 being the name of the executing file (not always) but in ruby similar to $0.

The “%~dpn0” in last line I think stands for “d(rive)p(ath)n(ame)” but 0 ? maybe something with extension. I don’t really know. I am rusty witn bat arguments processing.

and the last %* bit just collects the rest of arguments. You can make a temp.bat file and put this line in it.

REM "%~d0", "%~p0", "%~f0", "%~n"

this should be a fun exercise.

So. If you have ruby files that you want to execute from the command then put a windows path to ruby directive as the first line

#!C:/RUBY/bin/ruby.exe

and save the file without any extension to a dir that’s in your path (I use ~/bin or in windows speak USERPROFILE\bin )

Deconstructing Rspec Runner

2009-04-24T12:28:46-05:00

For my Watir ‘usecase’ tests I have been running test/unit test cases with the UI::Console::TestRunner.run . The reason is that I need to decide ‘when’ to run some test and when to run some ‘setup usecase’ routines. In a ‘functional test’ steps of execution sequence and timeline matter while in classic unit tests you assert ‘state and behaviour’ of a class in isolation.

In Functional tests I have to setup preconditions: load the browser and login. These ‘steps’ are tests as well in their own right but mostly they play a ‘role’ of ‘flow setup’ for later tests hence they introduce dependency in ‘functional testing’. This dependency rarely exist in Test Unit style testing, it is built to not care about this kind of ‘dependency setup’ – as a matter of fact it rejects it, it does not run test_xxx methods sequentially by default but alphabetically (this fact causes constant questions on watir-general mailing list. The fix is to use Watir::TestCase that sorts them sequentially).

How Test Unit runs tests

By default if you run a file with ruby testfile.rb that containes Test Unit TestCase the code will be loaded in ObjectSpace and massaged, counted sorted and then executed one by one. Each TestCase class is independent of another. Each test_xxx in independent of another test_xxx. TestCase is usually a collection of tests using the same test fixture. The fixture is setup and teardown for each test.

This simply will not do for my ‘browser functional tests’ because I need to be able to specify ‘when’ I want the tests to start and ‘when’ to finish. The question of ‘WHEN’ is important in functional sequential tesing. I test by moving from context to context and each tescase has a role that introduces dependency for the next testcase. The entire model of TestUnit her fails for me when it comes to flow based customer facing tests.

My cruch so far has bee to disallow the automatic TestCase runs but instead I invoke them at a particular time with the UI::Console::TestRunner.run. Here is how I weave them into my test infrustructure code.

# get testrunner 
require 'test/unit/ui/console/testrunner'

# run some code for context setup
# get the testcase code and run it with TestRunner.run
require 'my_testcase'
Test::Unit::UI::Console::TestRunner.run MyTestCase

# and clean up context and setup for the next test
# do some code for next context setup
# get the testcase2 code and run it with TestRunner.run
require 'my_testcase2'
Test::Unit::UI::Console::TestRunner.run MyTestCase2

or when I run a ‘usecase scenario’ I feed tests into ‘timeline’ like so

@test_list = %w[MyTestCase MyTestCase2 MyTestCase3]
def run_test(test_number)
  TestRunner.run @test_list[test_number].constantize
end
# setup context for test 1
run_test 0
# setup context for test 2
run_test 1

This code organization ensures the ‘when’ Test::Unit will run and ‘when’ it finishes. Now I can control the flow of test setups and I can use testcases as ‘roles’ to play some part in moving context forward in timeline of step sequence to run yet more tests.

Replacing TestUnit TestCase with Rspec ExampleGroup

Now I want to move to rspec and duplicate this same runner functionality. The Rspec style BDD block looks like this

describe "Something" do
  it 'should be named someting' do
    "something".should == "something"
  end
  it 'should not be something else' do
    "something".should_not == "something else"
  end
end

The above ‘syntax’ of describe blocks can be also written as class objects (which will perhaps take away some of the magic from it)

class SomethingExamples < Spec::Example::ExampleGroup
  def should_be_named someting
    "something".should == "something"
  end
  def should_not_be_something_else
    "something".should_not == "something else"
  end
end

and you can exeucte it just like you execute describe block.

how rspec executes tests.

There are usually 3 ways you would execute rspec examples.

With ruby
With spec executable
With Rake::SpecTask

Usually when you have a file.br that containes code that is wrapped in %describe do end@ block all you need to do it is add a line %requrire ‘spec/autorun’@ and run the file. The autorun will take care of invoking rspec. Similar with the spec executable you provide one or more files to run and they execute (in sequance).

The drawback is that any code that is not called from the describe blocks will be executed first an then at_exit all the examples will run. Hm… that’s not good for me. I either have to go with rspec runner or I am out of luck.

With rspec is it any reason to even have code outside of it? Maybe I need to rethink my strategy.

Anyway, I started writing this thinking I need to find an equivalent to TestRunn.run TestCase mechanism but now I am thinking maybe rspec itself is just it and there is no need to run outside of it.