logo logo

Mega Function – One Function To Rule Them All

main post image

At the end of the previous decade, when I was first exposed to an automation framework (in days of QTP and VB-Script), I met Matilda. Matilda was the name of Mega Function, one function that does everything! In our project, whatever we wanted and everything we asked for – Matilda provided it.

Nowadays, according to various Design Patterns and modern development methodologies (such as SOLID), we know that in order to create an automation framework we need to break everything down into variables and make each class and each function into a separate process that will later work in harmony by the test case (@Test).

During many encounters I had with several high-tech companies, I was exposed to many techniques and methodologies, and among them was Matilda that I’ve first met over a decade ago…

One Function that Controls All

Do you remember the beginning of the first movie of “The Lord of the Rings” Trilogy?

“It began with the forging of the Great Rings. Three rings were given to the Elves, immortal, wisest and fairest of all beings… Seven rings were given to the Dwarf Lords… and nine rings were gifted to the race of Men… but they were all deceived for another ring… one ring to rule them all…”

Matilda is that “one ring”, Matilda is one function to rule them all:

Mega Function – One Function To Rule Them All

The idea behind this name which comes from the legend is to create a single united interface for our tests, by creating one function that will categorize and divide our requests. Kind of a dispenser. This function will receive several parameters and know accordingly to which to send the request – it will call helper functions (some call them plugins) to execute the actions.

For example, let’s go to Wikipedia and look for “high-tech” in the search field. From the drop-down list, we’ll select the value “Hebrew”, click on the search button, and on the new page that loads – validate that the word “Tadiran” (“תדיראן”) exists.

wikipedia search

wikipedia search

Our test case may look like this, assuming we have used a separated framework that’s divided into different classes with a set of different actions:

@Test
public void test01()
{
    mainPage.updateText(pageObjects.searchField, "היי-טק");
    mainPage.updateCombo(pageObjects.dropDownMenu, "עברית");
    mainPage.clickSearch(pageObjects.searchButton);
    resultsPage.verifyText(pageObjects.textField, "תדיראן");
}

We see here the use of Page Objects while calling for an object of the class that represents the same area in the application, for example: mainPage is an object of the class that represents the main Wikipedia page.

In this case, we can see a call to only 2 objects here, but this is a very simple and short example test case. We can have calls for dozens of different objects within our test case, something that can confuse automation practitioners when it comes to writing the tests. A long test case can amount to the following actions:

Navigate to site: Virtual store -> Register in the designated form -> Enter the site with credentials -> Select products category -> Search product -> Filter the search (price, location, delivery fee…) -> Select product -> Transfer to shopping cart -> Confirm shopping cart -> Go to payments page -> Enter personal details and credit card number -> Confirm data -> Purchase.

In this case, we will have to call 13 different objects (and there are even longer test cases…) from 13 different classes.

So… I’m pleased to introduce you to Matilda!

Matilda is just a name. You can call this function any way you want to of course. When we decide to work with Mega Functions like Matilda to write test cases, we will only use Matilda’s API. Not 13 different objects, not dozens of functions, but rather one function that is “behind the scenes” and will already know how to call the relevant function according to the parameters sent to it. As I said before – dispenser, huh? 😉

Here for example is a simple case of a Matilda implementation:

public void mathilda(WebElement elem, action act, String value, controller cont)
{
    switch(act)
    {
        case click:
        {
            click(elem);
            break;
        }
        case update:
        {
            if(cont.text.toString().equals("text"))
                updateText(elem, value);
            else
                updateDropDown(elem, value);
            break;
        }
        case goTo:
        {
            driver.get(value);
            break;
        }
    }
}

What do we see here? 🕵️‍♂️

A function that receives a WebElement object on which it will perform the action, the type of action (enum) that can be expressed in a click, updateText, updateDropDown, goTo, etc., the value we want to add into the element (if we want), and the type of controller (which is also enum).

Inside we map the action and call the relevant function according to the mapping.

The Matilda function will be included in the project that will include files and additional classes. For example, in another class we can implement the functions of the actions, as follows:

public void click(WebElement elem)
{
  elem.click();
}

public void updateText(WebElement elem, String value)
{
  elem.sendKeys(value);
}

public void updateDropDown(WebElement elem, String value)
{
  Select select = new Select(elem);
  select.selectByVisibleText(value);
}

While this is a very simple use case, we can now easily expand the function’s capabilities, add reports or logs, insert waits with timeouts, etc.

While using Matilda, there is no prevention to continue working with Page Objects as there is no connection between the two. In the Page Objects classes we will identify the elements, whereas the Matilda class will be responsible for performing the actions on them (the same elements will be sent to Matilda as parameters).

Login Page Example:

public class POLogin
{
  @FindBy(how = How.NAME, using  = "username") public WebElement userName;
  @FindBy(how = How.NAME, using  = "password") public WebElement password;
  @FindBy(how = How.CSS, using  = "button[type='submit']") public WebElement submit;
}

And our tests will look as follows (example of entering PHP Travels site):

@Test
public void Test1()
{
  mathilda(null, action.goTo, "https://www.phptravels.net/login", null);
  mathilda(login.userName, action.update, "[email protected]", controller.text);
  mathilda(login.password, action.update, "udemouser", controller.text);
  mathilda(login.submit, action.click, "", null);
}

As you can see, everything is orchestrated by calling Matilda who is responsible for:

One Function to Rule Them All! 💍

I must say that today there are only a few places where Mega Functions are used. Most people go by more modern methods (rightfully so), but still, this is a methodology that used to be very popular in the past and figured it deserves its own post 😎

Yoni Flenner

About the author

Yoni Flenner

A software engineer who likes to test things programmatically, and he’s doing it for a living for the past 10 years: https://atidcollege.co.il

Join TestProject Community

Get full access to the world's first cloud-based, open source friendly testing community. Enjoy TestProject's end-to-end test automation Platform, Forum, Blog and Docs - All for FREE.

Join Us Now  

Leave a Reply

popup image

Complete E2E Automation Solution!

Join over 80K users (from Wix, IBM, Payoneer and many more!) using the world's first FREE cloud-based test automation platform, supported by the #1 testing community.
Sign Up Now right arrow
FacebookLinkedInTwitterEmail