This is the seventh part of a series of blog posts. Care to go back to the beginning?
Tinkering with Ruby only for the past year, Rubocop, a "Ruby static code analyzer and formatter, based on the community Ruby style guide" according to their Github site is both a blessing and a curse for someone new to the language. It is blessing that it is so detailed with output. The curse is that if you are new, it is going to take a lot of random Googling to figure out what all the errors thrown actual mean!
There is a lot of content in the Ruby Style Guide...
What is the Ruby Style Guide?
From the Ruby Style Guide README: "This Ruby style guide recommends best practices so that real-world Ruby programmers can write code that can be maintained by other real-world Ruby programmers. A style guide that reflects real-world usage gets used, while a style guide that holds to an ideal that has been rejected by the people it is supposed to help risks not getting used at all—no matter how good it is. [...]
"There are some areas in which there is no clear consensus in the Ruby community regarding a particular style (like string literal quoting, spacing inside hash literals, dot position in multi-line method chaining, etc.). In such scenarios all popular styles are acknowledged and it's up to you to pick one and apply it consistently".
This is the sixth part of a series of blog posts. Care to go back to the beginning?
Want to view JavaScript errors in Chrome? Or see if your Selenium WebDriver instance is throwing any errors? Check out the Logging Preference Capabilities from the Chromium project.
With this article, we will demonstrate how to get these logs set up in your Capybara-Ruby project, and what to add in the spec_helper.rb file we created.
With this entry, we will be activating Chrome in Headless Mode, i.e. running Chrome but without a visual interface, allowing the tests to run faster.
About Headless Chrome
According to Eric Bidelman's article, Getting Started with Headless Chrome, the new option of running Chrome in Headless mode started with Google Chrome version 59, released in May 2017.
Before, you had to use something such as PhantomJS to emulate the Chrome browser if you wanted to run Chrome in a place where the processing power to bring up a visual window would be a waste, such as running it with an automated test script running in a continuous integration environment. Now, it is built right in.
This is the second part of a series of blog posts. Care to go back to the beginning?
With the last entry, we analyzed the App Under Test, Dave Haeffner's The-Internet and came up with some test specifications. With this entry, we will be setting up the Ruby environment that will be running the Capybara-Gauge tests.
For the past year, my job at work has been to create an automation framework that monitors daily our web-based application, putting it through its paces. This project will be showcasing tools and technologies used to compose the framework, but most importantly, the thought process analyzing the site to determine what to test.
Our application under test for this project will be an old favorite of mine: The-Internet, created by Dave Haeffner, author of the SeleniumGuidebook.com -- which comes in C#, Java, JavaScript, Python, and Ruby editions -- and the very helpful blog ElementalSelenium.com.
The tools we will be using:
ThoughtWorks Gauge, to set up the tests in a human readable fashion
Capybara, to handle interaction between the tests and the browser
With Integrated Development Environments (IDE), I am quick to adopt whatever the rest of the developers on the team use. For Java development, I like IntelliJ IDEA Ultimate Edition. For JavaScript, Atom.io. And for writing the Capybara + Ruby framework, I have also been using Atom. The problem is that the BDD framework we are using at work -- Gauge -- has plugins that help refactor Gauge tests written in Java, but hasn't had anything for refactoring Gauge tests written in Ruby... until now.
With this blog article, I will be investigating Visual Studio Code -- commonly known as VS Code -- and how it helps refactor tests.
Why am I currently using Ruby for my automation framework if the BDD Framework hasn't supported it? Both Chef.io -- what I use to spin up virtual environments -- and GitLab.com -- the code storage / continuous integration environment also uses Ruby.
Let's say we wanted to test something out on Ubuntu, a popular Linux distribution, on a MacBook: How would we be able to set it up locally, configuring the workstation? We set it up in Docker before. What other ways are there?
One way to do it is with a Chef.io tool to spin up a test environment, Test-Kitchen, and its Ruby gem. And, yes, this cooking metaphor is extended all throughout the Chef toolset with its cookbooks and recipes for environment configurations.
Test-Kitchen on GitHub as a primary source: builds a Vagrantfile, allowing you to create or destroy the instances of your virtual machines
Vagrant: "a tool for building and managing virtual machine environments in a single workflow. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases production parity, and makes the "works on my machine" excuse a relic of the past".
Oracle's VirtualBox: "VirtualBox is a cross-platform virtualization application. What does that mean? For one thing, it installs on your existing Intel or AMD-based computers, whether they are running Windows, Mac, Linux or Solaris operating systems. Secondly, it extends the capabilities of your existing computer so that it can run multiple operating systems (inside multiple virtual machines) at the same time."
The past three years as an automation developer, I have worked with many different continuous integration platforms such as Jenkins, TeamCity, and CircleCI, hooking up my automation to it so the tests can be run once an hour, nightly, or every single time is checked in.
Threat Stack uses GitLab for its Continuous Integration / Continuous Deployment (CI / CD) pipeline. Why? You should ask Pete Cheslock, head of DevOps. He is currently writing about his experience in our company blog:
With GitLab, I am more concerned with finding out what it does in general. Lucky for me, they give YouTube tours such as this one shot back in November 2017, Idea to Production with GitLabs.
This video gives you a good idea of using GitLab to do issue tracking, planning, committing to the repo, testing with CI, debugging in the terminal, deploying to production, scaling an application and application performance monitoring.
"2011: Our CTO Dmitriy needed an great tool to collaborate with his team. He wanted something efficient and enjoyable so he could focus on his work, not the tools. He created GitLab from his house in Ukraine. It was a house without running water but Dmitriy perceived not having a great collaboration tool as a bigger problem than his daily trip to the communal well. [...] So together with Valery, he started to build GitLab as a solution for this. This commit was the very start of GitLab.
"2012: GitLab.com: Sid saw GitLab for the first time and thought it was natural that a collaboration tool for programmers was an open source so you could contribute to it. Being a Ruby programmer he checked out the source code and was impressed with the code quality of GitLab after more than 300 contributions in the first year. He asked Hacker News if they were interested in using GitLab.com and hundreds of people signed up for the beta. In November 2012, Dmitriy made the first version of GitLab CI".
Wait a Second... GitLab Uses Ruby?
Oh, that is interesting! GitLab is coded using Ruby! The Test Engineering team picked the Ruby language for its automation framework because Chef and Test Kitchen use Ruby. As a Ruby Newbie, I have been finding it helpful to review the great work the Gauge.org people have done creating examples using their BDD framework with Capybara.
What I find more fortunate is that it appears that GitLab uses for its UI tests what I am attempting to use: Capybara + Ruby + Headless Chrome.
As Mike put it, last year, "news spread that Chrome 59 would support a native, cross-platform headless mode. It was previously possible to simulate a headless Chrome browser in CI/CD using virtual frame buffer, but this required a lot of memory and extra complexities. A native headless mode is a game changer. It is now possible to run integration tests in a headless environment on a real, modern web browser that our users actually use!
"Soon after this was revealed, Vitaly Slobodin, PhantomJS's chief developer, announced that the project would no longer be maintained".
At my job there are so many things that are new to me:
I am new to Gauge.org
I am new to Ruby
I am new to Capybara
I am new to GitLab
I am new to Headless Chrome.
... For the last week, since I was placed on Threat Stack's UI team, I've written a few UI tests, but they all run locally, on my own computer, but I was stumped when it came to using CI with GitLab. I've been searching for a model to base my new framework on.
I am brand-new to Gauge and using Selenium-Ruby. So far I only have used Selenium-Java.
It looks like Gauge strongly advocates against page objects calling them an Anti-Pattern. Er... Um... burying a page's locators in code, as they do in the blog makes me worried. I am looking for other solutions.
When it comes to automation toolsets, I am up for learning anything! I'm always eager to adopt whatever toolset a company is already using. Right after my first automation gig, I would attempt to lobby the team to use what I knew already, not confident in my own ability to drill down into the details with a new tool. Now that I have had a few years of experience of learning toolsets on the job -- and with this blog -- I am more confident in my ability to do Just-In-Time Learning.
After a bit of quibbling -- we are doing BDD? Why not Cucumber? Why Ruby? -- I hunkered down and try to learn what they were already using at my new job: Gauge, a BDD automation framework brought to you by Thoughtworks - India.
Now, to put all that knowledge that I think I have to the test! I could start with CodeWars or HackerRank...
Instead, I wanted to check out the site Franklin Webber mentioned in his webinar, Exercism.io, an open-source practice area written by a former JavaRanch.com volunteer.
When it comes to programming languages, I am pretty language agnostic. With only three years of work experience developing automation, I am still learning, adopting whatever toolsets and technologies my employer already is using.
Sure, I still prefer Java, but only because it was my primary language back in grad school. Although I only consider myself a junior Java developer, I still think of it as my mother tongue.
2014: As the manual tester supervising an offshore automation team, I tested out and tinkered with the Calabash / Ruby code they were using to automate mobile apps.
2015: Selenium WebDriver/ Java was used to write the automation framework in my first job as an automation developer.
2016: Pairing with the Node.js product, I adopted Nightwatch.js to write tests for a Vue.js JavaScript-based front end.
2017: Appium / Java was selected in a mobile testing proof-of-concept I was creating.
2018: My new upcoming SDET job uses Chef. Chef uses Ruby. Therefore I need to re-learn Ruby.
For the past week, I've been trying to do a cram session on Ruby, one of the many programming languages I will be using in my next job as a Software Developer in Test.
Why Ruby? Chef, A DevOps tool, is written in Ruby... a language I don't even know.
The quickest way to learn how to swim? Row your boat into the deepest part of the lake and jump right in. Try not to drown too much.
Likewise, the quickest way I have found for me to learn? Dive right in. See how how long I can tread water before choking, sputtering, and coming up for air.
