Skip to Content

I know late again, sorry. My excuse this time? I’ve just bought a Garmin Edge 305 GPS for my bike and I seem to have become obsessed with riding, my bike that is! Now down to business, last time we wrote our first test script this time we’re going to use the Ruby unit testing framework to run the script.

OUR FIRST TEST CASE

First create a new file called c:\watir\scripts\myfirsttc.rb with the following content. I know this code does not look particularly good in HTML but should be OK to cut and paste into an editor. Note to self: Find out which tags to use for posting code to your SAP blog!

require 'watir'


require 'test/unit'


class MyFirstTC < Test::Unit::TestCase


def setup


@ie = Watir::IE.new


end


def test_login


@ie.goto('http://sweet:50000/irj/portal')


@ie.text_field(:id, 'logonuidfield').set('myuserid')


@ie.text_field(:id, 'logonpassfield').set('mypassword')


@ie.button(:name, 'uidPasswordLogon').click


assert(@ie.contains_text('Bahh I failed!'), 'Text not found!')


end


end


def teardown


@ie.close


end

Now lets just break this script down and explain the new bits.

REFERENCE THE TEST LIBRARY

We need to reference the Ruby Unit Test Library this is done with one simple line, nothing new here.

require 'test/unit'

THE TEST CASE CLASS

To use the unit test framework our class needs to inherit from the Test::Unit::TestCase base class. This is done using the Ruby operator ‘<‘.

class MyFirstTC < Test::Unit::TestCase

THE SETUP METHOD

Before each test method the setup method automatically runs, this allows you to do any required setup before a test method is run. The setup method runs before EVERY test method so if your test case class contained 100 test methods the setup method would be run 100 times. In our case we simply create a class level variable called @ie which will be available to our test method.

NOTE: The @ symbol is significant as this is how Ruby defines class level variables.

def setup


@ie = Watir::IE.new


end

THE TEST METHOD

Now this is were our actual testing goes on. One thing to note about our test method is it must start with the prefix ‘test_’ this simple naming convention is how the test framework knows which methods are test methods and which are not. So we call out login test ‘test_login’.

def test_login


@ie.goto('http://sweet:50000/irj/portal')


@ie.text_field(:id, 'logonuidfield').set('myuserid')


@ie.text_field(:id, 'logonpassfield').set('mypassword')


@ie.button(:name, 'uidPasswordLogon').click


assert(@ie.contains_text('Bahh I failed!'), 'Text not found!')


end

The code goes to our portal url fills in the logon fields, clicks the logon button and finally our actual test comes in the form of an assert method call.

assert(@ie.contains_text('Bahh I failed!'), 'Text not found!')

The assert method checks that the first parameter equals true, if not it raises and error and displays the descriptive message. So this line is actually saying if you cannot find the text ‘Bahh I failed!’ then raise an error and display the message ‘Text not found!’. Now I know we’re not going to find the text ‘Bahh I failed!’ during this test but to be sure the test is working we MUST first make it fail. Also I want you to see what happens when we get a failed assert.

NOTE: The Ruby unit testing framework has a lots of different assertion methods which you will want to checkout.

THE TEARDOWN METHOD

The opposite of the setup method the teardown method is called automatically after each and every test method. In our case we simply close Internet Explorer.

def teardown


@ie.close


end

THE RUN

Now that we know what the script is doing lets run our test. Open a DOS window and type the following commands.

cd c:\watir\scripts


ruby myfirsttc.rb

Again you should see an Internet Explorer window open with your portal login page showing. The User ID and Password fields will turn yellow as they are filled with the values from your script. The Log on button will turn yellow as it is clicked and finally the Internet Explorer will close and you will be returned to your DOS prompt. You should now see some report text output from the test framework.

c:\watir\scripts>

ruby myfirsttc.rb

Loaded suite c:/watir/scripts/myfirsttc

Started

F

Finished in 5.609 seconds.

  1) Failure:

test_login(MyFirstTC) c:/watir/scripts/myfirsttc.rb:20:

Text not found!.

THE REPORT

Although it does not look like much and there is no fancy GUI do not be deceived there is quite a bit of information here. First it tells us how long the tests take to run.

Finished in 5.609 seconds.

Next is a list of failures which shows the name of the method which failed and the line number of where the failure occured in this case the method test_login at line 20.

1) Failure:

test_login(MyFirstTC) c:/watir/scripts/myfirsttc.rb:*20*:

We can also see the descriptive message we used in our code and also the actual Watir error message.

Text not found!.

NOTE: A test method can contain as many assertions as you like. In fact it is usual that a test method will contain several assertions, they are after all the core of your tests.

FIXING THE TEST

Ok we’ve seen a failing test so lets go ahead and fix it. We simply need to change the assert line to look for a different piece of text. Lets look for ‘Log Off’ as we should see this text if our log on was successfull right?

assert(@ie.contains_text('Log Off'), 'Text not found!')

Run the test again using THE RUN procedure above. You should now have a passing test. Congratulations!

Started
.
Finished in 5.359 seconds.

1 tests, 1 assertions, 0 failures, 0 errors

HUNDREDS OF TESTS

So that’s one test but how do you run hundreds of tests? Simple add more test methods to your test case class. When you run the test case the framework will pickup your new test method and run that too. I tend to have one test case class for each module I am testing and add new test methods as I go. Eventually you will end up with hundreds of tests and the total confidence in your code which comes along with it.

COMING UP IN PART FIVE

That’s quite big post (for me anyway!) so I’ll leave it there until next time when we’ll go through my top tips which should help with your testing. That is providing I can stay off my bike for long enough to write it!

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Christopher Griffin
    Hi Justin,

    Fantastic blog, thank you!  One small problem I’m curious about:

    My IE window doesn’t close after the script is run.  Any ideas why this is?  Will this be a problem in later tests?

    Thanks
    Chris

    (0) 
    1. Justin Ramel Post author
      Hi Chris,

      Glad you’re enjoying the blog!

      If you can give me a little more info about the problem I’ll see if I can help.

      When you run your test script do you get an error stating why the IE window is not closing?

      If you do get an error could you post the message?

      If not could you post your test script?

      It should not cause any problems with your tests but you will get lots of open windows!

      Cheers,

      Justin

      (0) 
      1. Guido Humberg
        Hi Justin,
        I adapted your script to my portal and I faced the same problem as Chris: The IE explorer window did not close.
        Besides that, the output looked exactly the same as you described it in your blog.
        So everything is fine, but the IE did not close.
        Any hints?

        Thanks in advance,
        guido

        (0) 
        1. Justin Ramel Post author
          Hi Guido,

          Sorry for the slow reply my proper job is manic at the moment!

          Same questions as Chris really if you can give me a little more info about the problem I’ll see if I can help.

          When you run your test script do you get an error stating why the IE window is not closing?

          If you do get an error could you post the message?

          If not could you post your test script?

          Cheers,

          Justin

          (0) 

Leave a Reply