lilydbarrett.com

In addition to enjoying hacking sessions with my fellow Launch Academy grads at District Hall, attending tech meetups and events, and having conversations with strangers on the T about Silicon Valley culture, I’ve spent the past couple of months learning new things. In addition to honing my Ruby skills, I’ve tried my hand at AngularJS. I learned how to make better use of the Foundation framework’s responsive components. I checked out an online, interactive C# tutorial. And my recent obsession is with a testing tool: Selenium.

I love coding and building apps from the ground up, but I also really geek out about writing tests. As a person who’s already wired to think through all the different possible scenarios for a conversation, a project, a dinner party — after all, which creative writer isn’t? — I get a kick out of brainstorming different use cases and their various outcomes. For example, if you’re testing a typical registration form on a website, you may want to test the following:

• When a user navigates to the page, they should see the sign-up form. That’s it; They should just be able to actually see it.
• When a user fills out the form, they are required to enter their first name, last name, email, and password. If they attempt to complete the form without these elements, they should, perhaps, see an error message and be prompted to try filling out the form again.
• When a user hits “Submit,” the data should save to the back-end database, and the user should see a “Successful Sign-Up!” message.
• The form has an extra, non-mandatory field: Phone number. The user should be able to submit the form with or without a phone number entered.
• The phone number and email should be in valid formats.

And the list goes on and on.

At Launch Academy, we were encouraged to code to the test. In other words: Write our tests first, run them and watch them fail, and then write the necessary code to pass each test one at at time.We used a testing framework called Capybara to actually mimic the user and make sure — for instance — that when a theoretical user navigates to a registration form, the app allows the user to complete all of the actions described above.

We also used a different framework, RSpec, to make sure our code (methods, classes, etc.) functioned as expected. In my capstone project for Launch Academy, HyperLocal, I called upon RSpec to test whether an organization possessed valid data. Did it have a cause — education reform, environmental protection, income disparity — associated with it? Would the database accept both “MA” and “Massachusetts” for the state field in an organization’s registration form? RSpec helped me answer these questions.

RSpec and Capybara have served me well. But, really, I’m writing this blog post to tell you how great Selenium is. At the recommendation of a QA Engineer I spoke with, I dove into the documentation for Selenium WebDriver and tried writing some basic tests.

Selenium WebDriver makes direct calls to a browser and seems to mimic the user, similar to Capybara. It also allows you to identify UI elements on the page by class name, ID, CSS selector, etc. When you run the test, the browser launches and you watch as an invisible, automated user goes through all the steps you’ve laid out in your test. If you’ve included command-line instructions in your test — i.e., a requirement to print “Wowza!” upon a successful test — you’ll also be able to check your console to see if all is well.

Using Ruby, I wrote a test for Google Search, ensuring that I could look up “Star Wars” and see appropriate results, which was a lot of fun. I used the “Inspect Element” tool on my browser to identify the correct classes, names, etc. for UI elements.

Clapping my hands with glee over Selenium’s power, I then wrote simple tests for HyperLocal‘s homepage and one software development company’s API registration page.

Selenium’s documentation was super helpful, and I’d definitely recommend checking it out and playing around with the WebDriver tool.

Happy testing!