Tips for creating a testing "framework" using Watir?

Question

I'm fairly new to writing test cases and this will be my first major project, but I'm kind of confused on how to design a framework (I know this is not the right word, but I'm not sure that word I'm looking for here).

The application that I am testing involves creating a database of clients by filling out web forms and under each client are other forms that can be filled out and saved. The system is a bit more complicated than that as there are conditions that must be met before certain forms are filled, or certain answers cannot be chosen unless some preconditions are met.

From my research, I've seen that a good way of going about this is by creating a module for every page, where a method is defined for each function on that page.

So by that idea, for a page with lets say 40 text fields, would I create a method for each text field called "fill_fieldname"?

I'm also concerned as to how I would go about atomizing the test cases when there are preconditions. For example if I need to test a specific form's functionality, I would first need a client to exist. Should I create a new client for every scenario that I'm testing, or just use one client for all the scenarios? I suppose that I'd have to do a precondition check before each test case to ensure that the client is still "usable" for testing...

I'm really confused as to where to start, and I'd like to very much design a good framework from the get go, rather than have to scrap everything after the project has gotten too large. Any tips/advice would be very much appreciated.

Answer 1

Most folks are going to pair watir-webdriver with an existing page framework like cucumber or rspec for organization and validation. After that, I believe you were referring to page object pattern framework for ease of use and ease of expansion. You can find some great guides here:

• A simple Cucumber + Watir page object pattern framework
• UI Tests – Default Data
  (make sure and check out the more recent posts here)

Writing the test cases manually is a very important step of any automated process. Someone once said that automation without quality manual strategy lets you make mistakes much faster than you normally could (I'll take credit if no one else does).

Hopefully you have some good documentation for the application or someone providing you business/use cases for the product. It is very easy to generate test cases from business cases. Then, just go step by step and break it up in feature sets.

It can also be difficult to think about the application end-to-end and try to encompass all of that functionality in your tests from the start. Before you have a robust framework, you may just have some simple tool-type tests that help you set up manual testing faster, or perform tests with meaningful (but not beautiful) output. It's all part of the process. You WILL scrap some of what you do, but of course you don't want to scrap ALL of it. Keep it simple, make it modular - all traditional development concepts like DRY, KISS apply here.

Good automated tests are born from great manual test cases. If you try to skip this step (and don't have extensive experience), you will regret it!

There are lots of good testing books. I personally enjoyed Lessons Learned in Software Testing - one of the authors is Bret Pettichord, the founder of WATIR.

Once you get the testing fundamentals down, you can get into library-specific books like the WATIR Book, or many of the online blogs linked to/from the aforementioned Watirmelon and Cheezy.

Answer 2

I too, have had to start this - using Selenium (C# bindings) and NUnit.

The Page Object pattern is what you are referring too. It's entirely down to you whether you have a 'Fill_TextBox' method in your page object, for each textbox in the page, but you can also group them into one single method. For example (pseudo-code, in C#):

private void FillTextBox1()
{
    // fill text box 1
}

private void FillTextBox2()
{
    // fill text box 2
}

private void FillTextBox3()
{
    // fill text box 3
}

private void FillTextBox4()
{
    // fill text box 4
}

public void FillTextBoxes()
{
    FillTextBox1();
    FillTextBox2();
    FillTextBox3();
    FillTextBox4();
}

[Test]
public void TestTextBoxes()
{
    LoginPage loginPage = new LoginPage();
    loginPage.FillTextBoxes();
}

That is one way of doing it. You know from the method name of what the general idea of what it is doing, so if you need to you can step into it to find out exactly what textboxes it is dealing with.

I originally started off with creating a new client for each test, and it works well in most cases but in other cases things can get a bit sticky - if the previous browser doesn't shut correctly for whatever reason, you can run into a few problems. Meeting it in the middle, NUnit has TestFixture, or classes that contains tests, so we create and open up the browser to set up the TestFixture, and at the end of each test within that class, we ensure we get to a reasonable clean state for preparation for the next test - for most cases this is basically signing out of the application, leaving the next test to start from the login page. I've seen lots of discussion about it - you'll have to see what works best for you. It does cut down on time if you don't constantly have to shutdown and create a client per test.

Answer 3

I'm also concerned as to how I would go about atomizing the test cases when there are preconditions. For example if I need to test a specific form's functionality, I would first need a client to exist. Should I create a new client for every scenario that I'm testing, or just use one client for all the scenarios? I suppose that I'd have to do a precondition check before each test case to ensure that the client is still "usable" for testing...

In my experience I would say it is vital for everything that is required for the test to be set up fresh before the test starts.

This can be quite time consuming when you're running hundreds of tests, but necessary. If you aren't starting from the same point each time, it's going to be an unreliable test.

Create a new client each time.