AMA: JS vs Ruby

Butch Mayhew asks…

I have noticed you blogging more about JS frameworks. How do these compare to Watir/Ruby? Would you recommend one over the other?

My response…

I had a discussion recently with Chuck van der Linden about this same topic as he has a lot of experience with Watir and is now looking at JavaScript testing frameworks like I have done.

Some Background built an entirely new UI for managing sites using 100% JavaScript with React for the main UI components. I am responsible for e2e automated tests across this UI, and whilst I originally contemplated, and trialled even, using Ruby, this didn’t make long term sense for where the original WordPress developers are mostly PHP and the newer UI developers are all JavaScript.

Whilst I see merit in both views: I still think having your automated acceptance tests in the same language as your application leads to better maintainability and adoptability.

I still think writing automated acceptance tests in Ruby is much cleaner and nicer than JavaScript Node tests, particularly as Ruby allows meta-programming which means page objects can be implemented really neatly.

The JavaScript/NodeJS landscape is still very immature where people are using various tools/frameworks/compilers and certain patterns or de facto standards haven’t really emerged yet. The whole ES6/ES2015/ES2016 thing is very confusing to newcomers like me, especially on NodeJS where some ES6+ features are supported, but others require something like Babel to compile your code.

But generally with the direction ES is going, writing page objects as classes is much nicer than using functions for everything as in ES5.

Whilst there’s nothing I have found that is better (or even as good) in JavaScript/Mocha/WebDriverJS than Ruby/RSpec/Watir-WebDriver, I still think it’s a better long term decision for to use the JavaScript NodeJS stack for our e2e tests.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

8 thoughts on “AMA: JS vs Ruby”

  1. The current automation framework I’m working with is Ruby based but I have toyed with the idea of changing to JS as the majority of the devs have JS knowledge, I thought it may encourage them to get more involved.
    However the web application we are testing against has many dependencies and I have found libraries/gems such as ActiveRecord and Rest-Client invaluable.

    Do you find that JS testing frameworks are best suited to Front-End only automation? Or have you come across any JS libraries that would/could enable you to connect to DB’s, query rest api’s, etc.


    Liked by 1 person

    1. Do you find that JS testing frameworks are best suited to Front-End only automation? Or have you come across any JS libraries that would/could enable you to connect to DB’s, query rest api’s, etc.

      We use lots of libraries to do these type of things in Node and there seems to be plenty. We use mailosaur for our email verification and can use a library for this, and we use a slack reporter to post failures to Slack, again this is easy to do in NodeJS.

      I imagine it would be equally easy to find tools to do what you need in NodeJS as it would be in Ruby.


    1. Do you mean the new user interface for Or the move from Ruby to JavaScript?

      The new interface is entirely different than the old and there were never e2e tests for the old interface so we can’t doing any benchmarking.

      The e2e tests I developed in ruby were very basic before I decided to switch to JavaScript so there’s no way to compare the efficiency of them as they’re very different.


  2. IMHO it comes down to how much your org is doing ‘Silos’ vs ‘Embedding’ as relates to QA staff, and test automation.

    If you are in a more old-school org with a dedicated team doing E2E/Functional automation, separate from your application coders, then you can choose your platform based on what’s easiest for that Silo to deal with. That’s a case where I think Ruby/Watir-webdriver/Rspec/Cucumber can make an excellent choice.

    OTOH if you are doing more nu-skool “Agile Testing” where testers and coders work side by side on small teams, then it makes sense to use the same tech-stack for E2E/Functional automation as is being used to code the application. That allows your primary coders to assist with automation, and perhaps more importantly with maintenance. The ability for a programmer who’s introducing a change that breaks tests, to also check in the fixes for the tests all in the same pull request is a ‘really good thing’.

    One of the larger challenges with E2E tests is keeping them working, and not having folks ignore them due to ‘expected failures’. That is made worse if developers who break tests can’t fix them due to silos or language barriers. It is greatly reduced if everything is in the same tech stack and you can enforce a “you break it, you fix it” policy for acceptance tests.

    So for more modern agile orgs, you would use Ruby and watir-webdriver if your programmers are doing stuff in Rails/Rack/Sinatra/Cuba/Volt/Lotus etc. OTOH if your folks are using Node/React/Angular etc then you are likely going to want to look towards Webdriver.js/Mocha/Cucumber.js for your acceptance testing.

    Liked by 1 person

    1. We’re in a unusual situation where is very agile in they way they deliver product features (by flow, continuously) by small product teams, but we also have a small dedicated QA team who has responsibility for the e2e tests that cover user journeys across all the product features that various small teams work on. So when something breaks we need to determine which product team has ownership of this.


Comments are closed.