For Just a Few Lego Bricks More

Awhile back I had the chance to get an amazing deal on Lego bricks. Having 4 daughters, my wife and I notice when there’s a chance to give our girls something educational to play with.

I ended up getting 40 pounds of Lego bricks from a lady whose kids were old enough that they weren’t interested in them anymore.

After sifting through them to pick out all the Barbie shoes and G.I. Joe heads and pieces of chewed gum (gross!) I looked at what I had in front of me.

Strewn across the entire kitchen table, I realized: I must have like 1000 kinds of Lego bricks here. Not just differing by color, I mean at least 1000 different shaped pieces.

And I’m sitting there looking at all these Lego bricks and thinking: I would have to know about each kind of piece and which pieces they connect to (and how), and I literally don’t have the brain space to know all that stuff just to make something.

And I had no idea what I could build with them.

How this ties into test automation

This reminded me of a time when I worked on a project where I needed to clean up some automation that had gotten so big and sprawling that people were really afraid to use it. Maintenance was a nightmare, and changing one thing could break dozens of tests.

Get this: There were over 2000 specialized actions that were being done as part of these tests. 

I know right? I had the same reaction.

Now don’t get me wrong. They meant well. But a big reason why the automation had gotten like that was because a larger consultancy came in on a fixed bid contract and wrote a specialized method for more complex operations. They did get it done quickly (at a cost to this client) but left a steaming mess that was hard to maintain (also at a cost to this client)

Going forward, there were a few reasons why this had continued to be a problem before I joined the team:

• People didn’t know what methods were already written. Things weren’t cataloged very well and so people had to spend time looking through the code to find something that may or may not have even existed.
• People didn’t want to ask questions. In an environment where everybody’s understandably busy people were hesitant to ask for help. So more time was spent in an “analysis paralysis” phase instead of being productive.
• People just wrote new code to solve their problems under a tight deadline. I totally get it, I’ve been there. But it left a lot of code lying around that nobody really had time to understand and simplify, and so the problem just got worse.

Curious to know what 3 principles lead to great test automation?

So let’s take a step back here and ask ourselves:

What actions are we really doing on a website?

Look at your hands. What are they doing right now? Using a mouse? Clicking things? Typing text?

What are your eyes doing? Reading text? Locating things to interact with? Fact checking?

There are really very few things we need to do when we’re simulating a test for a website. So if we boil it down to basic (and I mean basic actions) we can create some powerful Lego bricks to build out models to test with.

Let’s talk about clicking. Do you have to have a special method that knows how to click “this specific button” on “this specific page”?

Or can you make a generic method that knows how to click a button, that takes in some data to specify which button?

Or can you make it even more generic and make a method that knows how to click, but also takes in what type of element is being clicked?

How about entering text? What if instead of keeping track of hundreds or thousands of unique locators, you could find a textbox based on information that’s already on the screen?

Locating a textbox can be as simple as looking at a neighboring label, or the placeholder text in the box itself. Setting text in that element is simple, it’s just a matter of finding it first.

What about verifying data? What are we trying to verify? What is it inside? A table? Textbox? Dropdown?

Do we need a special method to look in an exact spot for an exact phrase? Probably not.

Is there a generic way to confirm what we’re looking for is where we think it would show up? Probably so.

Not only are there are many ways to condense code into something simpler, but it’s much simpler to describe a test to someone else.

It’s pretty close to documenting what you’re doing with your hands and eyes. 

Coming back around to Legos again

If you’ve ever heard of Legoland you’d know that their trademark is huge models of animals and buildings. Like full size elephants and giraffes and stuff.

What you may not have realized is: they don’t use a ton of specialized bricks for this. They use standard bricks that you can find in most any beginner or intermediate set.

You can make big and complicated looking models out of Legos, using very few types of bricks which all connect with any other brick, and any color you can think of. Your imagination is the limit.

And you can make big and complicated looking tests out of some basic actions. Particularly for UI testing, breaking tests down into intuitive “bricks” that you barely have to think about creates ease of maintenance, high usability and makes the testing framework so much easier to extend.

Your imagination is the limit 🙂

How’s your automation looking?

If you’re reading this and thinking, “Yeah, the automation where I work is really difficult to use and maintain,” there’s a good chance you’ve got a lot of specialized pieces of code where a handful of generic ones would work better.

Code Remediation is one of the services that Arch DevOps provides. It’s often much easier and cheaper to refactor already-working code than to scrap it and start fresh. It’s a solution for the budget-minded manager that can get a lot more mileage out of the solution that you’ve already invested so much time, money and energy in using.

Would you like to schedule a chat? Link’s right here.

Fritz