Wherein Ruby beats Python. Smashes. You might even say defenestrates. Take it from a QA automation dev who’s used both for years: it’s not even close.

Long ago in the 00s and early 2010s, Rails ruled the earth, and Ruby was on everyone’s minds. But at the same time, Python was being introduced at high schools and universities, and young devs burned their initial brain cells on Python, not Ruby. Joining the workforce, they were eager to quit studying and actually do something. After years of school, who wants to learn another language ?

Thing is, especially in QA Ruby’s strengths of elegance, brevity and metaprogramming are hugely helpful. Python has some of these tools, but there’s a lot missing, and often a lot of unnecessary work to get there.

And in the underachieving world of QA automation, we need all the help we can get.

Python’s whitespace delimiting is a real problem

I started my automation career in Python. At the time, I thought enforced whitespace was cool ! Make the codes line up, everything looks so neat and tidy !

But you don’t know what you don’t know, and I didn’t know jack-all back then:

  • First of all, use your damn editor to keep indentation clean. It’s not complicated.

  • Second, monkeying around with indentation levels to control logic, sucks.

  • Third, debugging errors caused by Python indentation problems, really sucks.

  • Fourth, since Python actually uses indentation to control logic, you can’t even do #1.

By using indentation to define code blocks, Python has created a bunch of new problems, unnecessary ones, and potentially catastrophic if you get it wrong. And your editor can’t help you figure it out. All to solve a cleanliness problem which doesn’t really even exist if you use … well, any editor, really.

It was a cool idea I guess in the early 90’s, sort of. Today it’s just awful.

Compare then to how Ruby handles delimiting blocks:

def hello
  print "world!"
end

We end code blocks with … “end” ! What a concept !! Not even a curly brace !

Stupid whitespace versus stupid simple.

Modules, imports, facepalms

Somehow, Python’s import + module system has evolved over time into a real mess. It’s frustrating, because according to the classic Zen of Python, “There should be one – and preferably only one – obvious way to do something”. I was such a huge proponent of this Python-ism in the early days. How did things go so wrong ?

  • “Modules” don’t exist as a specific keyword or construct. Rather, we have to manipulate directories and the horrible __init__.py file .

  • Directory management gets complicated real quick, especially nested subdirectories.

  • We end up often falling back to setting $PYTHON_PATH behind the scenes, causing a whole new set of side effect debugging problems.

Compare to Ruby’s implementation:

# utils/mail/mailer.rb
module Mailer
  def self.send_newsletter(email_address)
    # send all the things
  end
end

# app/orders.rb
require '../utils/mail/mailer'

def email_customers
  @customers.each do |c|
    Mailer.send_newsletter(c.email)
  end
end

That’s it ! We declare a module with the keyword ‘module’, and we “require” aka import with a string that points to a directory structure. Simple ! Effective ! Done !

More examples

List comprehensions are great … if you’re a computer.

apple_list = [x for x in fruits if "apple" in x]

Can you read this left to right out loud and explain what’s going on ? It’s a syntax for computers, not for human speech. I defy anyone to call it “elegant”, especially compared to Ruby:

apple_list = fruits.collect {|f| f.include? 'apple'}

Collect everything from fruits that includes ‘apple’. Easy. Done.

Does one see a theme developing here ? Overly complicated, inefficient, head-scratching on the one hand; on the other, straightforward, elegant, simple.

Communities + Humility

The founder of Ruby is well known as a soft-spoken, humble individual, to the point that the Ruby community has a saying, MINASWAN: Matz Is Nice And So We Are Nice. Fantastic !

Meanwhile in JS, buh-millions of developers crack away at ludicrous speed, and JS framework fatigue is for real. But the TC39 group seems to be doing a good job of managing the constant flux in a transparent, diplomatic way. Maybe it’s due to JS’s historic connection to browsers, and the need to placate different implementations and still maintain a good customer experience. They’ve got plenty of experience trying to keep everybody happy.

The Python community, unfortunately, has a reputation and some significant evidence for epic dissent and nastiness. The prime example: back in 2018 the founder himself decided to vacate his position. His parting words: “I don’t ever want to have to fight so hard for a PEP and find that so many people despise my decisions.”

Now as a writer of technical blog posts, your author does love a dose of sarcasm to keep the masses interested. (Masses! I tell you.)

However, when it comes to actually getting work done as a professional, a humble approach is best.

Developer happiness means developer productivity

Among Ruby’s founding principles are beauty and “developer happiness”. Here’s what Matz himself has to say:

The goal of Ruby is to make programmers happy. I started out to make a programming language that would make me happy, and as a side effect it’s made many, many programmers happy.

I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy. That is the primary purpose of Ruby language.

As it turns out, happiness also makes a ton of money. First of all, your developers are more motivated, energetic and fresh. More importantly, there’s a strong tendency to call out when something isn’t working smoothly, and try to envision a pleasant alternative.

Ruby’s evolution, consequently, remains exciting and fresh. Elegance and happiness continue to reign as guiding principles, and it shows throughout the language and the community.

Wrapping up

For QA automation, Python is a big improvement over Java. Honestly, the jump from Python to Ruby is a similar order of magnitude. It’s that much better.

If you haven’t tried it, then you don’t know. Your author has done, however and here are the results: time saved, less bugs, far more simplicity, better quality, and a happier QA team.

Here’s to happiness, then. Cheers !