test objects design

I have been reading on Model View Presenter and especially Presenter First pattern. . I was reading it thinking about Watir Test Framework where View is a Layer or Adapter that talks to Watir which talks to the browser. In this way View is ‘dumb’ – just an interface to Browser(and can be treated as Adapter so you can swap IE for FireFox).

Since I am tesing a GUI story I think that my Presenter should be some kind of a Class that’s modeling a UseCase (you can call it Story or Feature). I would model the Presenter as a collection of methods reflecting UseCase Scenario interactions, behaviours and I would keep the Model as rules and data in one class because I would not want to spend a lot of time building a Model, I am testing the Application and most of the time I don’t have a lot of information so I would just grow the Presenter organically, my tests are Exploratory so I ‘discover’ and ‘learn about’ Model as I build tests. I think it would be a waste of time to build Model separately. I just treat it a a ‘dumb’ set of data that I store in hashes. My goal is to create cheap GUI tests built for frequent View changes so all my test logic is in the Presenter that has ‘dumb’ data model and ‘dumb’ View (well, an adapter I would think)

In the paper on Presenter I really liked this quote about why it is not good to go View First route

Starting with the view seems quite logical when following a customer prioritized eature-driven development process. The logic of this approach is seductive: customer stories describe actions taken on the view and results shown in the view, feedback from the customer requires some interface for them to use the application, and the importance of the model (infrastructure) is minimized. Unfortunately view first is an easily made and expensive mistake.

In our experience, the best alternative of the three possibilities is to start with the presenter. By starting with the presenter, and organizing development around it, the application may be built from user stories following test-driven development practices.

Aha. This is the mistake that most Record/Playback Automated Testing tools make. They attach to the View First. Everything is managed by the View. Automated Tests are scripted as actions on the View, coupled to the view. It’s a mess to decipher and modify.

For example: a View First approach using Watir code would be to do this:

ie = Watir::IE.attach :url, /google/
ie.text_field(:name, 'q').set 'Watir'
ie.button(:name, 'btnG').click

Tester translates User’s intentions into View First test. What is shown in 3 lines of code?
1 – attach to browser
2 – browser has a text_field named ‘q’, find it and type text ‘watir’ into it
3 – browser has a button named ‘btnG’, find it and click it.

This is eaiser to read than other tools, cleaner API but in this View First the test is expensive to maintain yet so cheap to make. Cheap and fast to script if its intended usage is to thrown it away afterwords. But the expensive part comes with maintenance if those test are to bring value long term or when View changes.(I can revisit this later)

So a Semantic View wrapper can be introduced that is written in the language of Domain (User Domain, Business Domain). This would be mu dumb view adapter. I refer to it as Semantic Test Objects layer (that name just stuck with me) where Test Object is some Area of Interest to the Tester. So for example that same Google test can be expressed as: On Google Home Page set the term ‘Watir’ and click Search or simply : google ‘watir’. I think this is what a user would say, just google it.

How about modeling it this way in simple trivial form:

google 'watir'

#implementation can be
def google (term)
  ie.text_field(:name, 'q').set term
  ie.button(:name, 'btnG').click
end

In this example I only have a convenient wrapper on implementation. It does not decouple much but it’s a good step. Buidling futher I could do this:

module GooglePage
  def term
    @b.text_field(:name, 'q')
  end
  def search
    @b.button(:name, 'btnG')
  end
end

class GoogleTest
  include GooglePage
  def initialize
    @term = 'Watir'
    @expected = some links or stuff to look for
  end

  def run
    load_page
    enter_term
    click_search
    verify_results
  end
end

#execute test
GoogleTest.new.run

Now I think I am building a Presenter First type of Test where I will want to keep the View as a Semantic Layer included as module in my Test. Steps modeling user’s actions as methods. Model View as a member of Test.

This is a half baked idea (or maybe overbaked) but I can see that building GUI tests as UseCase type modeling with delegation to Semantic View Layer quite useful.

So dear readers, any thoughts, I would like to continue this

What I’ve noticed is that I don’t write a lot about Watir and my usage of Watir and I’ve also noticed that when I read a post about Watir I don’t comment and link to it. I guess I still treat it as an ‘underground’ or ‘unapproved’ tool and I don’t want to ‘be found out that I use it at work’ (a bit too late for that)

However, I am on a lookout for articles about ‘Watir’ that would give me ‘permission’ to talk about it at work. (that seems silly too)

I wonder if there are many other testers who use ‘Watir’ as an ‘unapproved tool’ who also look for articles to help them ‘legitimize the usage of Watir’ and Ruby for Web Testing.

So, after this short intro I think I would need to start jumping in to start writing more on ‘Watir’ anyway. (I am prompted more on more by this by reflecting on the Beekeeper Model that Pete Dignan mentioned once on #watir IRC)

From Bret’s blog announcement: “FireWatir 1.2.1 is Released (…) It also marks the merger of the FireWatir and Watir projects. Unlike Watir, FireWatir works on Windows, Mac and Linux”

more info here

This is great news. The tests written for IE will run in FireFox as well. This is a major step in adopting Watir as a Browser Driver for Functional GUI tests.

Good title, good intention, lots of work in implementation. The idea is that I don’t find a lot of time to dedicate to writing blog posts on my testing work, approach and so on so how bout my taking 3 minutes to just write, or 5 minutes or 7 minutes to write a bit. With time I may get good at it.

Most of my time these days is spent Functional Testing. Writing and executing Browser Tests with Watir gem. I have been trying to adapt TDD approach to GUI tests but it’s not working, I end up wiring my own UseCase modules and scenarios and runners. I see that ‘cucumber’ may be a way to do some of those tests but we’ll see.

So far I can say that tools like test/unit, test/spec, rspec, shoulda, woulda, coulda, wanna do da do not support this type of GUI sequential workflow tests. I guess these are the tests that Brian Marick calls Business-facing tests, and Workflow Tests.

Basically GUI Browser Tests are tedious because you deal with DOM as implemented by developers who just want to ship the data over to the browser and make it look decent. Most of the DOM ends up being presentation layer wrapper on data elements and I need Semantic Structure of the page for my tests. So I end up writing a Semantic View Layer on top of the DOM. Then I write a Model View of the Domain I am testing and mash the two in my Test Controllers. I view this as Quick MVC framework for Watir, splish-splay and flush, and I call it Watirloo.

More about this later.