Test.Bash(); 2021 - Share Your Current Tooling for Automated Testing - Butch Mayhew

Butch Mayhew has kicked off another of our talk topics on what his current tooling is for automated testing.

We’ll use this Club thread to share resources mentioned during the session and answer any questions we don’t get to during the live session.

3 Likes

Butch Mayhew’s Twitter and Blog Link

twitter.com/butchmayhew

Questions answered

  • Assuming the application you are testing is not in Ruby, by testers using their own language is it not slowing down collaboration with developers ?+ And it could duplicate the code to maintain (application and test) as developer must do their unit test with similar needs.

Questions to be answered

  • What are some good IDEs for Ruby? I’ve used Rubymine a bit (and I really like it!) but are there any others you recommend?
  • Is this the framework open source?
  • Any thoughts around legacy projects with tests that use older incompatible versions of Ruby) - maintain, convert, start over or depends?
  • Anyone here uses OpenAPI client generators to create API clients that you use for API tests ?
  • Why ruby over say: Java, Python, GoLang etc? what advantages does it offer that others don’t have. Or is this just a platform decision?

Resource:

3 Likes

I personally use ruby mine, but I’ve seen folks succeed with VS code and VIM. Really it comes down to whatever you feel most comfortable in. I have found with the framework we use, there isn’t a lot of ‘type ahead’ or ‘completion’ the IDE helps you with. I typically use the IDE as a test runner, debugger, and linter.

Currently, this is not open source. I don’t see it being open-source with the companies policies, but the logic shared in the talk should work across any codebase/framework.

This is a big it depends. My guess is you have experience or have a framework that is on Ruby 1.93 which was a popular build. Moving to 2.x or 3.x could be big jumps. What I’ve found is it is worth the investment in upgrading (convert) if you are still investing in the test automation framework. If it’s there running, providing value with very little maintenance or additions, I could see it making sense to just run on an older version (maintaining) with older libraries. If the framework is painful to work with I may look towards starting over or at least augmenting new coverage with a new tool… Though this has downsides as well, now there are 2 automation frameworks that need to be managed/maintained.

Open API is the evolution from swagger, which is what we built the spec builder off of. With some tweaking to our script, it would be relatively easy to consume an OpenAPI 3.x file into a bunch of templated spec files for our framework.

These are the points I shared in my talk:
Ruby is straightforward (Easy on the eyes)
It’s easy to teach
It has rspec (great test runner that many other frameworks have borrowed from over the years – beforeEach(), describe(), it())
It’s a pleasure to use (It makes me a happy programmer)
There is a great community to answer questions you have
It gets the job done

I would also add, we had developers that helped us build this tooling out, against a .Net product. We did have build tools written in ruby, so it wasn’t a brand new language to the devs/testers. Once we build a boilerplate framework, with our companies acquisitions there was a need to quickly spin up an automation framework for a new product. With RTAF we have been able to do that, and our company plans to grow through more acquisitions. That is one of the reasons we stick with it… NOTE: we do have products that we have acquired that have some test automation. Typically we continue to invest in whatever is there unless it’s hard to use/maintain. We currently have projects that are built on Java/Selenium (UI), Java Spring/Boot (API), Cypress (UI), and Robot framework: Appium/mobile Selenium/ui, Requests/api. So we are familiar and open to other frameworks and encourage those in our org where it makes sense.

3 Likes