Object Mentor Blog: Testing GUIs Part I: RoR.

Testing GUIs Part I: RoR.

Uncle Bob — Sat, 13 Jan 2007 17:24:00 -0600

Testing GUIs is one of the the holy grails of Test Driven Develoment (TDD). Many teams who have adopted TDD for other parts of their projects have, for one reason or another, been unable to adequately test the GUI portion of their code.

In this series of article I will show that GUI testing is a solved problem. Over the years the TDD community has produced and accumulated tools, frameworks, libraries, and techniques that allow any team to test their GUI code as fully as any other part of their code.

Testing GUIs Part I: Ruby on Rails

In the world of web development, no community has solved the problem of GUI testing better than the Ruby on Rails community. When you work on a rails project, testing the GUI is simply de-rigeur. The rails framework provides all the necessary tools and access points for testing all aspects of the application, including the generation of HTML and the structure of the resulting web pages.

Web pages in rails are specified by .rhtml files that contain a mixture of HTML and ruby code similar to the way Java and HTML are mixed in .jsp files. The difference is that .rhtml files are translated at runtime rather than being compiled into servlets the way .jsp pages are. This makes it very easy for the rails environment to generate the HTML for a web page outside of the web container. Indeed, the web server does not need to be running.

This ease and portability of generating HTML means that the rails test framework merely needs to set up the variables needed by the ruby scriptlets within the .rhtml files, generate the HTML, and then parse that HTML into a form that the tests can query.

A typical example.

The tests query the HTML using an xpath-like syntax coupled with a suite of very powerful assertion functions. The best way to understand this is to see it. So here is a simple file named: autocomplete_teacher.rhtml.

<ul class="autocomplete_list"> 
<% @autocompleted_teachers.each do |t| %> 
<li class="autocomplete_item"><%= "#{create_name_adornment(t)} #{t.last_name}, #{t.first_name}"%></li> 
<% end %> 
</ul>

You don’t have to be a ruby programmer to understand this. All it is doing is building an HTML list. The Ruby scriptlet between <% and %> tokens simple loops for each teacher creating an <li> tag from an “adornment”, and the first and last name. (The adornment happens to be the database id of the teacher in parentheses.) A simple test for this .rhtml file is:

  def test_autocomplete_teacher_finds_one_in_first_name
    post :autocomplete_teacher, :request=>{:teacher=>"B"}
    assert_template "autocomplete_teacher" 
    assert_response :success
    assert_select "ul.autocomplete_list" do
      assert_select "li.autocomplete_item", :count => 1
      assert_select "li", "(1) Martin, Bob" 
    end
  end

The post statement simply invokes the controller that would normally be invoked by a POST url of the form: POST /teachers/autocomplete_teacher with the teacher parameter set to "B".
The first assertion makes sure that the controller rendered the autocomplete_teacher.rhtml template.
The next makes sure that the controller returned success.
the third is a compound assertion that starts by finding the <ul> tag with a class="autocomplete_list" attribute. (Notice the use of css syntax.)
- Within this tag there should be an <li> tag with a class="autocomplete_item" attribute,
- and containing the text (1) Martin, Bob.

It should not come as any surprise that this test runs in a test environment in which the database has been pre-loaded with very specific data. For example, this test database always has “Bob Martin” being the first row (id=1) in the Teacher table.

The assert_select function is very powerful, and allows you to query large and complex HTML documents with surgical precision. Although this example give you just a glimpse of that power, you should be able to see that the rails testing scheme allows you to test that all the scriptlets in an .rhtml file are behaving correctly, and are correctly extracting data from the variables set by the controller.

An example using RSpec and Behavior Driven Design.

What follows is a more significant rails example that uses an alternate testing syntax known as Behavior Driven Design (BDD). The tool that accepts this syntax is called RSpec.

Imagine that we have a page that records telephone messages taken from teachers at different schools. Part of that page might have an .rhtml syntax that looks like this:

<h1>Message List</h1>

<table id="list">
  <tr class="list_header_row">
    <th class="list_header">Time</th>
    <th class="list_header">Caller</th>
    <th class="list_header">School</th>
    <th class="list_header">IEP</th>
  </tr>
<%time_chooser = TimeChooser.new%> 
<% for message in @messages %>
  <%cell_class = cycle("list_content_even", "list_content_odd")%>
  <tr id="list_content_row">
    <td id="time"   class="<%=cell_class%>"><%=h(time_chooser.format_time(message.time)) %></td>
    <td id="caller" class="<%=cell_class%>"><%=h person_name(message.caller) %></td>
    <td id="school" class="<%=cell_class%>"><%=h message.school.name %></td>
    <td id="iep"    class="<%=cell_class%>"><%=h (message.iep ? "X" : "") %></td>
  </tr>
<% end %>
</table>

Clearly each message has a time, caller, school, and some kind of boolean field named “IEP”. We can test this .rhtml file with the following RSpec specification:

context "Given a request to render message/list with one message the page" do
  setup do
    m = mock "message" 
    caller = mock "person",:null_object=>true
    school = mock "school" 

    m.should_receive(:school).and_return(school)
    m.should_receive(:time).and_return(Time.parse("1/1/06"))
    m.should_receive(:caller).any_number_of_times.and_return(caller)
    m.should_receive(:iep).and_return(true)

    caller.should_receive(:first_name).and_return("Bob")
    caller.should_receive(:last_name).and_return("Martin")

    school.should_receive(:name).and_return("Jefferson")
    assigns[:messages]=[m]

    assigns[:message_pages] = mock "message_pages", :null_object=>true
    render 'message/list'
  end

  specify "should show the time" do
    response.should_have_tag :td, :content=>"12:00 AM 1/1", :attributes=>{:id=>"time"}
  end

  specify "should show caller first and last name" do
    response.should_have_tag :td, :content=>"Bob Martin", :attributes=>{:id=>"caller"}
  end

  specify "should show school name" do
    response.should_have_tag :td, :content=>"Jefferson", :attributes=>{:id=>"school"}
  end

  specify "should show the IEP field" do
    response.should_have_tag :td, :content=>"X",:attributes=>{:id=>"iep"}
  end
end

I’m not going to explain the setup function containing all that mock stuff you see at the start. Let me just say that the mocking facilities of RSpec are both powerful and convenient. Actually you shouldn’t have too much trouble understanding the setup if you try; but understanding it is not essential for this example. The interesting testing is in the specify blocks.

You shouldn’t have too much trouble reading the specify blocks. You can understand all of them if you understand the first. Here is what it does:

The first spec ensures that <td id="time">12:00 AM 1/1</td> exists in the HTML document. This is not a string compare. Rather it is a semantic equivalence. Whitespace, and other attributes and complications are ignored. This spec will pass as long as there is a td tag with the appropriate id and contents.

HTML Testing Discipline and Strategy

One of the reasons that GUI testing has been so problematic in the .jsp world is that the java scriptlets in those files often reach out into the overall application domain and touch code that ties them to the web container and the application server. For example, if you make a call from a .jsp page to a database gateway, or an entity bean, or some other structure that is tied to the database; then in order to test the .jsp you have to have the full enabling context running. Rails gets away with this because the enabling context is lightweight, portable, and disconnected from the web container, and the live database. Even so, rails applications are not always as decoupled as they should be.

In Rails, Java, or any other web context, the discipline should be to make sure that none of the scriptlets in the .jsp, .rhtml, etc. files know anything at all about the rest of the application. Rather, the controller code should load up data into simple objects and pass them to the scriptlets (typically in the attributes field of the HttpServletRequest object or its equivalent). The scriptlets can fiddle with the format of this data (e.g. data formats, money formats, etc.) but should not do any calculation, querying, or other business rule or database processing. Nor should the scriptlets navigate through the model objects or entities. Rather the controller should do all the navigating, gathering, and calculating and present the data to the scriptlets in a nice little package.

If you follow this simple design discipline, then your web pages can be generated completely outside of the web environment, and your tests can parse and inspect the html in a simple and friendly environment.

Conclusion

I’ll have more to say about RSpec in a future blog. BDD is an exciting twist on the syntax of testing, that has an effect far greater than the simple syntax shift would imply.

I hope this article has convinced you that the rails community has solved the problem of testing HTML generation. This solution can be easily extrapolated back to Java and .NET as future blogs in this series will show.

Clearly the problem of testing Javascript, and the ever more complex issues of Web2.0 and GTK are not addressed by this scheme. However, there are solutions for Javascript that we will investigate in future blogs in this series.

Finally, this technique does not test the integration and workflow of a whole application. Again, those are topics for later blogs.

I hope this kickoff blog has been informative. If you have a comment, question, or even a rant, please don’t hesitate to add a comment to this blog.

"Testing GUIs Part I: RoR." by ping irons

Wed, 16 May 2012 02:23:05 -0500

Just know teachers collective strike, toping g20 driver blocking defaults salary ready to ‘run road’ boss.” The teachers that night to haikou meilan airport “intercept” and clashes happened.Hundreds of students and parents know the truth, worry about the tuition “skip stone”, also collective actionping g20 fairway woods find li wei money back. Teachers and parents in the police station found that li wei said the company account is only 600 yuan, can’t pay the teacher’s salary. But li wei denied “run road”, said that the company did not collapse, although there are a wage but have beenping g20 irons trying to make up for. According to preliminary statistics, the company defaults teacher pay plus education service fees have not yet provide a total of more than 100 ten thousand yuan.

"Testing GUIs Part I: RoR." by ???????

Fri, 11 May 2012 07:23:04 -0500

Strongly recommended for shopping at ??? منتديات

"Testing GUIs Part I: RoR." by Link Building Company India

Tue, 01 May 2012 14:35:25 -0500

Promote your websites with Linkbuildingtraffic.com: a search engine optimization and internet marketing company specializing in Professional Link Building + SEO and SEM services. please contact at Mail Id: linkbuildingtraffic@gmail.com

"Testing GUIs Part I: RoR." by Craig Chilvers

Tue, 01 May 2012 12:30:24 -0500

Your article is extremely impressive. I never considered that it was feasible to accomplish something like that until after I looked over your post . Please visit our website for more information .

"Testing GUIs Part I: RoR." by louboutin sales

Fri, 20 Apr 2012 18:17:01 -0500

Testing GUIs Part I: RoR. 137 hoo,good article!!I like the post!4

"Testing GUIs Part I: RoR." by you

Fri, 20 Apr 2012 10:36:48 -0500

I have bookmarked it. torrid coupons

"Testing GUIs Part I: RoR." by re

Fri, 20 Apr 2012 10:34:37 -0500

This is fantastic article. Medical billing and coding jobs

"Testing GUIs Part I: RoR." by youngbrown

Tue, 27 Mar 2012 03:46:26 -0500

Thanks for the information, I’ll visit the site again to get update information Toys

"Testing GUIs Part I: RoR." by taylormade r11 driver

Mon, 26 Mar 2012 20:12:20 -0500

to the hegemonictitleist 910D3 control of her life, love Ping G20 is not desire Continuous stretch of the war is about people’s nerves TaylorMade R11s Driverscut off powerful,

"Testing GUIs Part I: RoR." by china crafts

Wed, 07 Mar 2012 10:42:41 -0600

I wanted to thank you for this great read!! I definitely enjoying every little bit of it. I have bookmarked it to check out new stuff you post.

"Testing GUIs Part I: RoR." by Massagem Tantrica

Mon, 05 Mar 2012 16:11:40 -0600

They

’ll normally inform you whether the boots growing to be bought is

genuine or an imitation.

"Testing GUIs Part I: RoR." by Payday Loans

Thu, 16 Feb 2012 14:27:17 -0600

Great post! Thank you so much for sharing this article about Testing GUI’s.

"Testing GUIs Part I: RoR." by evdo wireless internet

Thu, 16 Feb 2012 06:01:56 -0600

That is one fine ride. The Shimano’s Dura-Ace Di2 and MSC Koncept frame are sublime. evdo wireless internet.

"Testing GUIs Part I: RoR." by iphone sms to mac backup

Wed, 15 Feb 2012 20:21:25 -0600

Most of us will delete the SMS file if the iPhone inbox is full. For some of the very important text file, you would like to save it to Mac hard drive and read it later or you need print them. So, why not export the text message to HDD and save it now?

"Testing GUIs Part I: RoR." by PDF ? PPT

Sun, 29 Jan 2012 19:05:30 -0600

PDF ? PPT PDF to PowerPoint Converter lets you convert PDF to PowerPoint (PPT, PPTX, PPS, PPTM, PPSX, PPSM, POT, etc.), fully supports MS 2010, 2007, 2003.

"Testing GUIs Part I: RoR." by shakopee townhomes

Fri, 20 Jan 2012 02:42:15 -0600

Thanks for the post. It was informative and interesting.

"Testing GUIs Part I: RoR." by Wholesale clothing manufacturers

Thu, 19 Jan 2012 22:04:01 -0600

Nice article, I’ve bookmarked this one.

"Testing GUIs Part I: RoR." by led displays

Fri, 13 Jan 2012 00:24:08 -0600

I have to say this is huge work.I have read the whole article and it is really superbly written article.Testing guis part 1 is really an informative article and wanna say we the readers wanna see some more like this.

"Testing GUIs Part I: RoR." by Urdu poetry

Thu, 29 Dec 2011 01:06:11 -0600

Thanks for sharing these wonderful comic videos with us. They are really funny. Will look after for some more updates.

"Testing GUIs Part I: RoR." by dentist in houston

Tue, 27 Dec 2011 09:16:02 -0600

First I must tell you we appreciate the great and informative entry.Need to admit that I never learned about this review, I noticed many new facts, in my opinion. God bless you for sharing this information useful and interesting and I also will probably anticipate other interesting posts you closer to the inside future.keep.

"Testing GUIs Part I: RoR." by Software Testing Services

Mon, 28 Nov 2011 00:17:44 -0600

The article very surprised to me! Your writing is good. In this I learned a lot! Thank you! Share with us the good times. <Software Quality Assurance

"Testing GUIs Part I: RoR." by banyo dekorasyon

Thu, 24 Nov 2011 06:48:34 -0600

Yes, I plan on discussing the testing of thick client GUIs, Banyo Dekorasyon and GUIs with lots of JavaScript.

"Testing GUIs Part I: RoR." by car rental service delhi

Thu, 24 Nov 2011 03:59:56 -0600

If only I had found this blog before. The advice in this post are very helpful and I will certainly read the other posts in this series too. Thank you for posting this.

"Testing GUIs Part I: RoR." by Cheap Beats By Dre

Tue, 15 Nov 2011 03:52:02 -0600

bus today, make them Cheap Beats By Dremiserable. One said: “I ??am really unlucky it! I was packed Beats By Dre Studioin the car to flow production.” One said: “I ??called Beats By Dre Soloit bad luck! In I was packed car are pregnant.Beats By Dre Pro Classic joke: I TVU A university studentbeats by dr dre caught by the enemy, the enemy tied him at the poles,just beats solo headphones purple and then asked him: say, where are you? You do not say it electrocuted! Scheap dr.dre beats studio headphones balck/yellowtudents back to the enemy a word, the result was electrocuted, he said: I am TVU.Hot sale beats by dr dre pro headphones

"Testing GUIs Part I: RoR." by Gate Valve

Mon, 07 Nov 2011 21:14:06 -0600

Thanks for sharing! please allow me to twitter it.