Introduction

Magium is a testing framework built on top of WebDriver. Why in the world do we need another framework? Let's frame the question differently. Why do very few people automate frontend testing?

My answer? While direct control over the browser gives you an immense amount of flexibility it takes a gargantuan amount of time to build the tests. A gargantuan amount of time equals a gargantuan amount of money.

Let's look at some of the math. But before we do that, let's look at a simple scenario. 

As a site visitor I want to add a product to my shopping cart and verify that it has been added.

There are a number of steps involved in executing that user story

  1. Open the website page
  2. Navigate to the category Accessories/Jewelry
  3. Navigate to a product
  4. Click the add-to-cart-button
  5. Verify that the product has been added to the cart with a quantity of 1

As a manual tester it takes about 15 seconds to do that test. But if you were to script that using Selenium it could take upwards of an hour, maybe even two, especially if Selenium testing is only one of the 50 things you do.

How about checkout? It takes about 45 seconds to test the checkout, front to back, as a manual tester. But it could take a full day to write the automated version of the test. Maybe even longer depending on what you all have to deal with. What would you rather accomplish? 100 tests per day or 1 test per day? I'm not great at math, but I'm pretty sure 100 tests per day is better than 1.

But why use Magium when a number of vendors are starting to include Selenium tests as part of their distribution? Nothing against these (really!). But, as with many things, there is a learning curve involved, and things are seldom clear. And, truthfully, learning yet-another-thing, one that has such a learning curve, makes it very difficult to make the case that your company should be automating browser testing.

Magium is different in that it is designed to be intuitively accessible. Individual actions are available in classes that are intuitively named and easily referenced in your IDE. That is why do you see code like this: 

$this->commandOpen($this->getTheme()->getBaseUrl());
$this->getNavigator(DefaultSimpleProductCategory::NAVIGATOR)->navigateTo();
$this->getNavigator(DefaultSimpleProduct::NAVIGATOR)->navigateTo();
$this->getAction(AddSimpleProductToCart::ACTION)->execute();

There are a few things to notice in that example.

  • Notice the command sequence. It is ordered in the same way as the user story, making it easy to follow the sequence
  • Notice the names. Are you at the point in the test where you want to add a product to the cart? Start typing addtocart and your IDE will start giving you options for the next command

So what if you could build the tests almost as fast as you can execute them? That's the goal here: to make it so easy to build baseline useful tests that you have no excuse to not build them. And run them over and over like the robots at a automotive assembly line. Obviously, I can claim that you can do that with Magium, but why don't we see it in action in the following video where a test was build AND executed in under two minutes.

The goal of Magium is to minimize boilerplate and maximize re-use. So if a pattern doesn't quite make sense try to apply it to those two conditions and hopefully it will be a little more clear.

There are several base concepts that you need to be familiar with

  • Commands - These tend to be basic WebDriver commands, such as open(). There aren't many of them.
  • Actions - These are sets of commands that do strings of things to get to a particular goal. One goal could be logging in. Another goal could be adding a product to the cart. Another could be checking out
  • Assertions - There are two types of assertions
  • Static assertions - These are the kinds of assertions that you find in your test case itself. assertEquals(), assertTrue(), etc. These are usually built into the AbstractTestCase
  • Programmable assertions - These are more complicated assertions that may be programmable.
  • Identities - Used to manage users, such as a customer or admin user.
  • Navigators - These classes will navigate to some place on the web site, but will not do any actions. They are intended to be read-only, in other words. Navigating to a product page. Navigate to a customer login page. Navigate to and admin System Configuration panel. And so on.
  • Themes - These are possibly mis-named. They are intended to contain configuration information about your specific Magento instance. So, if your customization has a different add-to-cart button you would either override these classes or provide configuration for internal use.
  • Extractors - These are classes that can be inserted in some execution flow to extract data from the page. Useful for assertions or for gathering data for further command execution.