Building a Test Framework: With Gradle, everything is Groovy

So far, we've seen how to set up the build dependencies in an automated test framework, using Gradle in both IntelliJ and Eclipse. Gradle is more than just a tool to set up build dependencies between third-party software and the Selenium WebDriver framework.  And with the hands-on learning you get from free courses that Gradle, Google, and Udacity put together, you can learn about how Gradle configures tasks, interacts with the file system, handles logging, works with repositories, and sets up tests.

I am really loving how Jeremy Silver explains things in the Gradle for Android and Java course he created on Udacity! Go here to sign up for the free course.

Although I studied it in college and grad school, I have not spent much day-to-day work as a coder until the past year. I love how he walks us through, step-by-step how to follow along with the Gradle exercises he has written, and how Gradle has been integrated with Groovy, a Domain Specific Language (DSL).

Free Udacity Course: Gradle for Android and Java

Want to more about Gradle? Sign up for a free course on Udacity!

Gradle for Android and Java 
https://www.udacity.com/course/gradle-for-android-and-java--ud867

https://www.udacity.com/course/gradle-for-android-and-java--ud867

When putting together an automation framework using Selenium WebDriver and Java, you need a way to store the dependencies. This is so you don't have to end up downloading every single third-party component, piece-by-piece. When I was taking a course in Selenium WebDriver 2 with Java, I was introduced to a tool called Maven to do this for me.

Maven was a pretty simple tool to set up. Gradle, though, is a bit more complex.

We have been using Gradle at my workplace ever since I first started my job as an automation engineer. It never was my job description to set up all the initial dependencies, the reporting and logging, design the build process, or set up the tasks, so Gradle was just another buzzword to me.

Lately, though, the senior members of the team have been using a lot more of its functionality. This is why, all of a sudden, blog posts on Gradle start appearing, such as:

• WebDriver development environment setup with IntelliJ, Gradle, Hamcrest, and ChromeDriver
• WebDriver development environment setup with Eclipse, Gradle, Hamcrest, and ChromeDriver
• A Quick Gradle Overview: Setting Dependencies and Running Tests

A Free Course in Gradle!

I was referred to a free course on Gradle through Gradle.org and its tutorial section.

The course was put together by Mark Viera, Core Engineer at Gradle, and Jeremy Silver, a Udacity course developer.

• Looking just for Gradle Information for your Selenium / Java automation framework? Take the first part of Gradle for Android and Java.
• Looking to build Android apps? Take Udacity's free course: Developing Android Apps: Android Fundamentals. 

A Quick Gradle Overview: Setting Dependencies and Running Tests

Since January of this year, our little automation department at work has been trying to re-align itself, getting more in line with what the other software developers are doing -- a fantastic (but scary) learning opportunity for me.

Back in March 2015, I was trying to relearn for loops and foreach loops in Java. By September, though, I was helping build out the automation framework for our Selenium WebDriver browser tests -- See Automate Amazon for a sample. And by January 2016, I thought I was really becoming an experienced developer, independently writing a framework to handle Rest APIs. All the extra work I was putting into learning to code was really paying off.

Now, I feel like I don't know anything!

We are switching from being an "Automation Department" to being a "Software Test Engineering" department, from just running browser tests to testing APIs and performance testing. I find myself experimenting with many languages and tools that are brand new to me... and one of them is the build management tool, Gradle.

Maven and Gradle: Setting Dependencies

As far as I knew, a build management tool was something you set up once at the start of the project to handle the dependencies, installing the tools you needed to create the framework, and then forgot about them.

Time Capsule: Ward Cunningham's Wiki Wiki Web

What year is it?

The last think I remember, I came home from work early, and sat down in front of my computer. I decided on browsing Ward Cunningham's Wiki Wiki Web  -- now over twenty years old!  -- as I have been doing lately, trying to get a feel what it was like in the early days of the Extreme Programming movement which became the Agile Alliance. Time sped by, and the next thing I knew it was close to midnight.

http://c2.com/cgi/wiki?WikiWikiWeb

What is Wiki Wiki Web?

From Wikipedia:

"The WikiWikiWeb is the first ever wiki, or user-editable website. It was launched on 25 March 1995 by its inventor, programmer Ward Cunningham, to accompany the Portland Pattern Repository website discussing software design patterns. The name WikiWikiWeb originally also applied to the wiki software that operated the website, written in the Perl programming language and later renamed to 'WikiBase'. The site is frequently referred to by its users as simply 'Wiki', and a convention established among users of the early network of wiki sites that followed was that using the word with a capitalized W referred exclusively to the original site".

"[...] The software and website were developed in 1994 by Cunningham in order to make the exchange of ideas between programmers easier. The concept was based on the ideas developed in HyperCard stacks that Cunningham built in the late 1980s. On March 25, 1995, he installed the software on his company's (Cunningham & Cunningham) website, c2.com. Cunningham came up with the name WikiWikiWeb because he remembered a Honolulu International Airport counter employee who told him to take the Wiki Wiki Shuttle, a shuttle bus line that runs between the airport's terminals. 'Wiki Wiki' is a reduplication of 'wiki', a Hawaiian language word for Quick. Cunningham's idea was to make WikiWikiWeb's pages quickly editable by its users, so he initially thought about calling it "QuickWeb", but later changed his mind and dubbed it 'WikiWikiWeb'.

Since I have been trying to somehow turn into a Real Programmer, I have spent a lot of time trying to learn how to incorporate Unit tests and Software Design Patterns into my automation development.

I stumbled on this site last year when I was trying to search for tips on Object Oriented programming.  and found out there were many definitions for what that means.

Watch out! You can spend hours trying to Find a Page and end up sucked in just like me.

Here are a few fun entries I found:

Writing Code

There is a huge section on Extreme Programming and Test Driven Development by Kent Beck that I would list as required reading for any manual QA person attempting to get into software development.

Make sure to read all about the Agile Manifesto.

After that is done, you can read about Software Design Patterns ( and the Gang of Four ) which help and AntiPatterns which hinder.

Around my workplace, the developers still talk about Design By Contract.

It also has entries on the two text editors still favored:

• Emacs
• Vi
• Emacs vs Vi: And old time funny flame war!

It has pages on the two main Integrated Development Environments (IDE) used now:

• Eclipse IDE 
• IntelliJ IDEA 2.0 

Writing Tests 

When it talked about Testing Frameworks I expected the section for JUnit written by Kent Beck and Erich Gamma. It also has a section on TestNG, added six years ago, probably by it's creator Cedric Beust.

They also cover various typed of Automated tests such as:

• Unit tests
• Acceptance Tests
• Regression Tests

Building Software

What intrigued me is showcased build tools such as:

• Apache Ant 
• Ant vs Make 
• Apache Maven 

... Nothing yet on Gradle, though, a build tool we are starting to use more extensively at work.

Wiki Wiki Web. It's a nice little time capsule.

Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!
// Check us out on Facebook!

What I get out of blogging about code

On my lunchbreak, I was trying to explain to my co-workers what I get out of blogging about code I am writing at work. 

You know the expression, if you really want to see if you know something, try describing it to someone else? 

That's why I blog. 

Software development is brand new to me. It was scary when I first started. I was completely out of my comfort zone. But it got better. 

What I am learn at work has been a good foundation. There, I learn about the what, and the how.

It isn't until I start organizing my thoughts, creating a blog post, do I figure out the why.

• How did the software development process I am using take hold? Who first blogged about the concepts I am using? Was it Kent Beck? Martin Fowler? Simon Stewart? Jim Evans? Uncle Bob? 
• Who made the toolset I am using? When did it become adopted? Is it industry standard?
• Although I may not understand it, where on GitHub is the open-source code? Can I understand how their project is constructed? Are there unit test formats I can borrow for my automation development? 

Through blogging, for me, comes understanding. 

And that's my thought of the day!

Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!
// Check us out on Facebook!

WebDriver development environment setup with Eclipse, Gradle, Hamcrest, and ChromeDriver

We started writing at work a new way of configuring an automated test framework. The original idea I had was that I could just bang out a simple automated test framework as practice, refactoring what I already have written in the past. When I started researching the new toolset, and my research notes were piling up, I then had the brilliant idea that this topic would make a lovely blog post.

I wrote about using IntelliJ. A reader asked me, What about an Eclipse version?

With this blog post, I will walk you through downloading Eclipse IDE for Java Developers, installing Buildship (the official Gradle plugin for Eclipse), setting up your Java environment, configuring Gradle, installing ChromeDriver, and creating quick-and-dirty WebDriver JUnit Tests, making assertions in the tests using Hamcrest, and refactoring those tests when we come across duplicate code.

This is a different setup than programming projects I have done before. We are using:

• Eclipse  with Buildship will be the Integrated Development Environment (IDE).
• Gradle to handle our dependencies, instead of Maven
• JUnit 4.11 as a test framework instead of TestNG.
• Hamcrest to handle the asserts, instead of the usual AssertTrue or AssertFalse found in JUnit or TestNG.

Please Note: You don't need an Integrated Development Environment (IDE) to code, just as you don't need Microsoft Word or any other word processing program in order to write a research paper. It is just easier to those who are more used to working with a Graphical User Interface.

If you want to be seen as a programming rock-star, learn to code in vim or emacs on a Unix command line. Me, I am more of a visual person and need the crutch of an IDE while coding.

WebDriver development environment setup with IntelliJ, Gradle, Hamcrest, and ChromeDriver

This blog post should be titled, "How I Spent My Memorial Day Weekend".

We started writing at work a new way of configuring an automated test framework. The original idea I had was that I could just bang out a simple automated test framework as practice, refactoring what I already have written in the past. When I started researching the new toolset, and my research notes were piling up, I then had the brilliant idea that this topic would make a lovely blog post. Hey, presto! Ten hours of my weekend disappeared, with me locked away in my home office, missing out on the pleasant sunshine we had. At least my wife and I managed to join the epic Space Battle on the Boston Common: Two hundred nerds swinging around plastic light-up lightsabers at each other.

With this blog post, I will walk you through downloading IntelliJ, setting up your Java environment, configuring Gradle, installing ChromeDriver, and creating quick-and-dirty WebDriver JUnit Tests, making assertions in the tests using Hamcrest, and refactoring those tests when we come across duplicate code.

This is a different setup than programming projects I have done before. We are using:

• IntelliJ will be the Integrated Development Environment (IDE).
• Gradle to handle our dependencies, instead of Maven
• JUnit 4.11 as a test framework instead of TestNG.
• Hamcrest to handle the asserts, instead of the usual AssertTrue or AssertFalse found in JUnit or TestNG.

Our Integrated Development Environment (IDE)

Please Note: You don't need an Integrated Development Environment (IDE) to code, just as you don't need Microsoft Word or any other word processing program in order to write a research paper. It is just easier to those who are more used to working with a Graphical User Interface.

If you want to be seen as a programming rock-star, learn to code in vim or emacs on a Unix command line. Me, I am more of a visual person and need the crutch of an IDE while coding.

How to Clone a Repository in IntelliJ

Want to fiddle around with any code that I have created on GitHub, such as RESTful Testing Using Stripe at https://github.com/tjmaher/RESTful_Testing_Using_Stripe?

This is a walkthrough on how to clone a repository through IntelliJ, an Integrated Development Environment (IDE) that I use for work.

What is GitHub, from How-to Geek:

"To understand GitHub, you must first have an understanding of Git. Git is an open-source version control system that was started by Linus Trovalds – the same person who created Linux. Git is similar to other version control systems – Subversion, CVS, and Mercurial to name a few.

Webinar Notes: Dave Haeffner, "Practical Tips and Automation Tricks For Selenium Test Automation"

If you are brand new to automated browser testing and are looking someone who can provide some hand holding, there is no better instructor than Dave Haeffner.

• See Spotlight on Dave Haeffner, June 9, 2015
• T.J. blogged about writing his first test framework against Dave’s test site.

Dave gave yet another wonderful talk on automated testing, sponsored by Sauce Labs.

From Sauce Labs:
https://saucelabs.com/resources/webinars/practical-tips-and-tricks-for-selenium-test-automation

"Want to learn how to use Selenium like a Pro? Join Dave Haeffner - author of The Selenium Guidebook - as he steps through the best and most useful tips & tricks from his weekly Selenium tip newsletter (Elemental Selenium)".



"Topics covered include:

• "Headless test execution
• "Testing HTTP status codes
• "Blacklisting third-party content
• "Load testing
• "Broken image checking
• "Testing "forgot password"
• "Working with A/B testing
• "File downloads
• "Additional debugging output
• "Visual testing & cross-browser testing"

Slides have been shared via SlideShare:

Practical Tips & Tricks for Selenium Test Automation from Sauce Labs

... The only problem I found with Dave's Elemental Selenium newsletter: Too much Ruby and not enough Java.

We use Selenium WebDriver 2 with Java for our automated browser tests at work. I can't just rip off or steal or copy or borrow or repurpose his code without much modification like I do on StackOverflow.

Hrm... I discovered like almost everything else worthwhile, code examples for Dave's Elemental Selenium tips are on GitHub!

It would be good practice for me to go over his code repository, find a chapter lesson that only lists only a Ruby example, and rewrite an example in Java.

This should be fun! Other than my fun little "weekend work" projects, I haven't made updates to anything besides Fitbit-Boston's test automation framework.

This should be fun! I think I found my next fun weekend work project!

Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

*DING!* 100th Post!

Wow. I can't believe that yesterday's post on Simon Stewart talking about Selenium WebDriver was the 100th post I have created here at Adventures in Automation.

This blog was started back on January 24, 2015 as a place to organize my research notes I collected as I was trying to break into the world of automated test development. Now that I am a full-fledged automated test developer, I continue to blog about whatever I am learning at work to help make the new concept stick, inventing new little side-projects to reinforce what I am learning. Hopefully these articles and code samples have helped you, too!

The act of putting together this blog has made me a better software developer.

Thank you, dear reader, for being a part of it.

Thank you most of all to:

• Alan Richardson, the Evil Tester
• Joe Colantonio, from Test Talks
• Matt Hutchinson, the Testing Curator
• Mr. Slavcheck 
• Petri Kainulainen 

... and anyone who has given me such excellent Feedback about this blog.


-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

Notes: Selenium 3, the Spec, and Onwards by Simon Stewart

Title: Selenium 3, the Spec, and Onwards
Speaker: Simon Stewart, Selenium Project Lead
Host: Applitools
Date: Wed. May 25, 2016 @ 1:00 PM EDT
Duration: 60 minutes

Summing up Simon's Webinar:

• Selenium 3 (no release date given) will be a removal of all old Selenium RC code into a legacy library called "leg-RC".
• Selenium 4 will move closer to the new W3C WebDriver Protocol they have been pushing for.
• Selenium 5 will be the full W3C WebDriver.

Before that information was given at the end of the talk, Simon took a long walk down Memory Lane...

Live Blog: 5/24/2016: Meet the Fitbit Security Team @ Fitbit-Boston

A few weeks ago, Fitbit's Security team organized a talk through the Security of Things Meetup:

What: Meet The Fitbit Security Team!
When: Tuesday, May 24, 2016, 6:30 PM
Where: 1 Marina Park Drive, Boston, MA
Signup At: http://www.meetup.com/The-Security-of-Things/events/231198245/ 

"[T]he folks at Fitbit have extended an invitation to the Security of Things Meetup: an opportunity to meet with Fitbit's product security team next Tuesday, May 24th at the FitBit offices in downtown Boston.

"This is a great opportunity to talk with the folks responsible for securing the hottest wearable technology in the market right now. Fitbit isn't just a wearable activity monitor: its a sensing platform for a wide range of health monitoring activities: from fitness and weight loss to sleep monitoring and social networking.

"Come hear about how the Fitbit team addresses the security and privacy challenges of its growing and enthusiastic user base, while also developing next generation features to keep their technology relevant and cutting edge".

Are you a Firmware / Embedded Engineer? Fitbit-Boston needs your help!

Are you a Firmware / Embedded Engineer? Fitbit-Boston needs your help!

From Jason Y. Sproul, Firmware Manager:

"We have launched a survey and sweepstakes focused on embedded/firmware test engineers in the Boston area. We want to learn more about the local job market, talent, and where people work so we can better focus our recruiting and hiring efforts. We want to build a great firmware test engineering team alongside our great engineering team.

"Entrants from MA, NH, ME, and RI can win a Fitbit Blaze for answering 6 quick questions. We’ve posted it on the Fitbit LinkedIn feed. Please like it and share it, or share the following link on social media!"

Survey Link: https://www.surveymonkey.com/r/bostonfwtesteng

Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

Switching from Manual Testing to an Automated Testing Career in Five Difficult Steps

It wasn't too long ago when I was an out-of-work software tester without much experience coding. There are many manual testers -- people who test web and mobile applications the same way customers use them, with a mouse, a keyboard, or a finger on a touch screen -- who are trying to switch to automated testing. I wrote at length elsewhere about my transition. With this blog post, I wanted to list more of a summary, hoping that other people in the same boat as I was would find it helpful.

Coding: Getting used to it

To get used to coding again, I worked through all of the examples in the free eBook Learning Python the Hard Way: http://learnpythonthehardway.org/book/ to get used to working with a programming language. I really needed the hand-holding this book offered. Working with Python helped, since it is a language with less ramp up time.

Then, I purchased Java for Testers at http://javafortesters.com/ to ease me into the Java programming language. Anything by The Evil Tester, himself, Alan Richardson, is made of awesome.

Java 8 and Python 2.7.11 seem to be the heavy hitters, when it comes to programming languages. Some companies are still trying to transition from Java 7 to Java 8, but they will do it eventually. Python 3? It came out years ago and hasn't been fully adopted yet. People would rather stick with Python 2 and pull in new features than switch to Python 3.

Doing the Coursework

I purchased Alan Richardson's online course Selenium 2 WebDriver Basics with Java: https://compendiumdev.zenler.com/courses/selenium-2-webdriver-basics-with-java ($299) ... Work through all the Preview material if you can to see if you like his course, his videos, his humor, and his Scottish accent.

I used Alan Richardson's mildly outdated Selenium Simplified free guide to Get Started: http://seleniumsimplified.com/get-started/ ... I set up IntelliJ as an Integrated Development Environment (IDE) on my home PC. Either this or Eclipse seems to be the new standard.

Doing the Coursework right!

When working through an online course, if it is showing in the video someone typing code into IntelliJ, I am typing, too!

The left half of my screen contains the video playing in a browser. The right half of my screen is filled is my IntelliJ window.

... The instructor types? I type. The video executes the code? I do too... I accidentally wasted two months simply passively listening to the lectures. I retained completely no information I supposedly learned.

Create Code of My Own

Once I got a hang of things, I started looking around for things to automate, such as Dave Haeffner's test site, "The Internet" on https://github.com/tourdedave/the-internet and http://the-internet.herokuapp.com/ .

Share the Code!

I signed up for a GitHub account, creating a coding portfolio displaying automation coding examples I came up with: https://guides.github.com/activities/hello-world/

Once I had the GitHub account filled with coding examples, I could prove to employers that I had what it takes to do the job.

Hope that helps!

Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

Adventures in Automation is now on Facebook!

Like Adventures in Automation?

Want to know when there are new posts to this blog but don't feel like Subscribing Via Email?

Visit Adventures in Automation's new Facebook page!

Careful! I think the paint is still wet there...

You can keep up with new posts either there, signing up to our RSS Feed, Subscribing Via Email, or Following me on Twitter at @TJMaher1.

And as always ... Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

Fitbit-Boston talks: Come hear about Fitbit and security, Tues. May 24!

If you happen to be in Boston, sign up to hear a talk given by the Fitbit Security Team, hosted by the "Security of Things" Meetup!

What: Meet The Fitbit Security Team!
When: Tuesday, May 24, 2016, 6:30 PM
Where: 1 Marina Park Drive, Boston, MA
Signup At: http://www.meetup.com/The-Security-of-Things/events/231198245/

From the Security of Things Meetup

http://www.meetup.com/The-Security-of-Things/events/231198245/

"[T]he folks at Fitbit have extended an invitation to the Security of Things Meetup: an opportunity to meet with Fitbit's product security team next Tuesday, May 24th at the FitBit offices in downtown Boston.

"This is a great opportunity to talk with the folks responsible for securing the hottest wearable technology in the market right now. Fitbit isn't just a wearable activity monitor: its a sensing platform for a wide range of health monitoring activities: from fitness and weight loss to sleep monitoring and social networking.

"Come hear about how the Fitbit team addresses the security and privacy challenges of its growing and enthusiastic user base, while also developing next generation features to keep their technology relevant and cutting edge".

Fitbit-Boston is a short walk from the Commuter Rail / Red Line stop, South Station at One Marina Park Drive on the 7th floor. ( map )
Happy Testing!

-T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!

STAREAST Notes: David Dang, "Open Source Test Automation: Riding the Second Wave"

David Dang, from Zenergy Technologies, VP of Automation Solutions, gave a very entertaining and humorous talk on a brief overview of test automation as it was, how it is now, and points to consider a company just starting out with test automation should consider. STAR East Virtual Conference, a TechWell Event broadcasted from Orlando, FL, Wednesday May 4th, 2016.

According to David's STAR East bio, "For more than seventeen years, David Dang has been a leader in the test automation industry. As VP of automated solutions for Greensboro, NC-based Zenergy Technologies, David spearheads the development of advanced frameworks that emphasize reusability and reduce maintenance efforts. He is an expert in all major commercial automation tools as well as open source tools such as Selenium and Jenkins. On the mobile front, David uses advanced concepts to design optimal frameworks using mobile automation toolsets including Perfecto and Appium. In addition to his high-level consulting engagements for Zenergy’s clients, David is in high demand as a presenter at major software quality assurance and testing conferences".

STAREAST Notes: Dorothy Graham detailing how planting a test automation framework is like caring for an orchard

Dorothy Graham ( @DorothyGraham ), a software tester for over forty years, spoke at the STAR East Virtual Conference, a TechWell Event broadcasted from Orlando, FL, Wednesday May 4th, 2016 during the Lightning Talks section, "Lightning Strikes the Keynotes". The following is a (mostly) accurate transcript of her talk, taken by T.J. Maher.

"Test automation is sooo easy.

"Let me rephrase that. Test automation seems to be really easy, at first. You can see your first demo, you write your first test [...] and it looks so easy!

"But if you want a long lasting asset for your company [...] that's a different matter altogether. It's like the difference between seeing some low hanging fruit, and picking the fruit off the tree and thinking, 'Wow, that was easy. This is so good!' and the other aspect: What if you want to build an orchard to grow enough fruit to feed a small town? It's an entirely different matter.

Builder Pattern: Creating an AddressBuilder

Earlier, I talked about why software developers would use a Builder Pattern to solve problems such as the bad habit of too many overloaded methods telescoping out of control. With this post, I was going to go over a bit more of what I have found, and give a simple example of an AddressBuilder.

Down the road, I was going to test out I could use this pattern to create a ProductBuilder (such as ALTA.BLK.LARGE.US) that I could use at my workplace.

Much further down the road, I was going to experiment with creating a TestBuilder, where I could set different test parameters, such as placing a standard shopping cart order with multiple products, set the shipping level, and payment types.

... For now, though, I'll stick with attempting to create an AddressBuilder.

Setting up a Virtual DEV Environment with VirtualBox, Vagrant, and Docker

The Source Material: Test-Driven Java Development

We will be covering in this blog post setting up a virtual development environment that has Ubuntu, Docker, and Mongo DB installed. We will using VirtualBox and Vagrant to set up the virtual machine.

Are most of the technologies I mention in the previous paragraph new to you? Me, too! I'm a software tester by trade, not a developer or a SysOps guy. We'll just have to figure out this stuff together!

As a guide, I purchased a copy of Viktor Farcic's Test-Driven Java Development, printed by PACKT Publishing. We will be using Chapter 2: Tools, Frameworks and Environments as source material.

Since I am doing this on my system at home, I will be setting it up on my Windows 10 machine. Feel free to use whatever operating system you have at home.

Notes on Accelerating DevOps Collaboration with Sauce Labs & JIRA

Name: Accelerating DevOps Collaboration with Sauce Labs & JIRA
Date: Tuesday, May 3, 2016, 2:00 pm
Webinar Host: Sauce Labs

About the Webinar:

"Software Development teams are looking for ways to speed up their development process while maintaining high quality applications. In order to help meet this challenge, Sauce Labs is proud to announce the release of the first automated test cloud integration with Atlassian's JIRA.

"The Sauce Labs Plugin for JIRA allows JIRA users to increase the speed of their development cycles while maintaining quality and reducing cost. The plugin seamlessly connects the rich testing metadata that Sauce Labs provides with an organization's JIRA instance. Teams who are looking to adopt DevOps/Continuous Delivery practices for the first time will find this tool especially compelling".

Why do Manual Testers Still Exist?

In the April 28th edition of the Sauce Labs blog, Joe Nolan ( @JoeSolobx ) Mobile QA Team Manager and founder of the DC Software QA and Testing Meetup posted an article, "Why is Manual QA Still So Prevalent?" In the article, Joe argues, "With the importance of catching bugs early, and the ability to automate all testing, why do companies and projects resist the investment in [Continuous Integration] and test automation?" and talks about an "automation first" strategy, building automation as the product is being built.

Joe then list reasons why not all companies have embraced automation, such as:

• Management -- except for the QA Manager -- doesn't articulate support for automation
• The development team hasn't giving the buy-in to be responsible for developing automation as they develop the product
• The QA Analyst has trouble committing the time to learn automation, doesn't know where to start learning, and not given a chance to apply knowledge once learned.

I agree with these points, especially the last one. After a long career as a Manual QA Engineer and a newly minted one as an Automation Developer, I don't know how I would have been able to manage in my new role -- although I was decade ago -- had I not finished grad school for software engineering.

My problem with the article is that I believe a manual tester should never be obsolete!

STAR East is streaming their software testing conference for Free!

Can't attend next week's excellent software testing conference, STAR East, in Orlando, Florida?

STAR East will be live streaming their Wednesday May 4th and Thursday May 5th session (8:30 am to 5:30 pm) for Free!

Why Use a Builder Pattern? Examples of Telescoping Constructors when storing Address data

Let's say you wanted to fill out the Billing Address of a form that has the following fields:

• Name
• Street Address 1 
• Street Address 2
• City
• State
• ZipCode
• Country

If you wanted to store this information into an Address object, the class could look like:

Address.java:

     

public class Address {

  private String name;
  private String streetAddress1;
  private String streetAddress2;
  private String city;
  private String state;
  private String zipCode;
  private String country;
  
}

How would we set these fields?

Elemental Selenium code examples are being written in Java!

I love reading Elemental Selenium, automation development tips written by Dave Haeffner -- who I have written about in this blog.

Archive of Dave's Weekly Newsletter of Automation Tips!

The only problem has been that Dave's language of choice for the code examples is in Ruby. Since I only have been just getting back into coding, I have had difficulty converting the code into Java, what I am using on the workplace.

There is hope! If you take a look on Dave's ( @TourDeDave ) GitHub site, you can find the corresponding Elemental Selenium Tips source code.

Switching Careers in QA: From manual testing to automation development

"Are you a manual tester? Are you attempting to switch careers in the software industry? Are you trying to break into automation development? In this article, I will outline how I made the transition from being a manual quality assurance engineer—a technical position that deals with next to no actual coding—to an automated testing position, where I am programming in Selenium and Java daily.

"This transition didn't come overnight. It took years to lay the groundwork for this career shift. Because I found the transition difficult, I'd like to share some pointers with other software testers who are in a similar situation in order to make their career shift easier than mine was".

Uncle Bob Martin: The Agile Manifesto, 15 years later

If you have ever wondered about the history of Agile Software Development ( which I have written about in this blog ) you should check out the new article published in TechBeacon, "Uncle Bob Martin: The Agile Manifesto, 15 years later", written by Malcolm Issacs.

"Robert 'Uncle Bob' Martin is one of the 17 software development visionaries who met at The Lodge at Snowbird ski resort in Utah in February 2001 to discuss the various lightweight development methods of the time. The result of that meeting would become known as the Agile Manifesto [...]

Let's compare notes on how we write an automated test framework!

Good day! I was wondering if I could bother you for a bit. I was working on two projects, one for creating an automated testing framework for an eCommerce site, and one for testing a REST API endpoint:

• https://github.com/tjmaher/RESTful_Testing_Using_Stripe
• https://github.com/tjmaher/automate-amazon

... I coded them as I would at my workplace.

I'd like to recruit other automated developers in the software industry to possibly take a look at it and give me their feedback.

Let's compare and contrast what we do in their own workplace.

Maybe we could compare notes?

Thank you very much for your time!

-T.J. Maher
  Sr. QA Engineer, Fitbit

 // Software tester since August 1996
 // Automation developer for [ 1 ] year and counting!

Automation Development Experience: Level Up!

[ T.J. Maher has reached Automation Development Experience: Level 1]

* ding! *

I can't believe I have now been an automated developer for a whole year!

I've had some experience executing before my current position executing other people's automation scripts. I've done lot of coursework with Alan Richardson's Selenium 2 with WebDriver. There is no substitute, though, for on-the-job experience, especially at the breakneck pace we are working at.

When I started off at my job, the Sr. Automation Engineer gave myself and another QA resource three weeks of private instruction for the next on how Selenium WebDriver / Java was used. Within just seven months I went from writing automated tests to writing an automated test framework. And just last month, I started writing API tests.

I owe a lot of my success in automation to this blog. I asked permission early on to blog about the automation code I am writing. As long as I just focus on the automation, it's fine. To deepen my understanding of what I am doing, I've been able to come up with little side projects, posting my code in my portfolio at GitHub.  So far, I've done:

• Testing The-Internet: Writing a framework vs Dave Haeffner's Login Page.
• Automate Amazon: Writing a framework vs Amazon.com's shopping cart
• RESTful Testing Using Stripe: Writing a framework to do API Testing vs a well-known payment processor. 

Are you an experienced automation developer? I was wondering if you could take the time to look at a few of the projects I have been working on and review the code? I'm still at the stage where because I don't have experience backing me up, I am just making it up as I go along. If you have the time, I would love to get your advise!

... Want to keep updated with what I am working on?

  Subscribe to the Blog: 

• Via RSS Feed
• Via Email

I am looking forward to the next twelve months. Who knows what fun projects I will encounter? All I know is that when it comes to writing automation, I am having the time of my life! 

Happy Testing! 

-T.J. Maher

 Sr. QA Engineer, Fitbit
 Boston, MA

// Automated tester for [ 1 ] year and counting!

Please note: 'Adventures in Automation' is a personal blog about automated testing. It is not an official blog of Fitbit.com. 

RESTful Testing with Stripe: From JSON to Object using GSON

This post is fifth in a series of six. Need to go back to the beginning?

With RESTful Testing with Stripe: Using UriBuilder, HttpGet and other Apache HttpComponents, we focused on laying groundwork for communicating with the Stripe API endpoint, sending messages and retrieving data.

• JSON response was retrieved
• JSON was converted it into a JSON string
• Google's GSON library was used to place it in a data object we created.

... But how exactly did this process happen?

Let's simplify things and set all the charge object data to null in our JSON file.

Do You Actually Know What Your Automated Test Is Doing?

When it comes to automated tests for your software application, what is more important?

• Knowing that a test passed or failed
• Knowing how a test passed or failed 

Without adequate reporting, you will never be able to tell what is being tested, how it is being tested, and whether the test is being thorough enough.

When I was a manual tester, I always made sure to write up a test case.

• Summary Heading : What I am hoping the test is going to accomplish
• Steps to Reproduce: A bullet pointed list of the specific parameters I am using to test the application, and where I am entering them.
• Results:  What did I expect the results to be? What were the actual results? Did it (PASS) or (FAIL)? 

The Steps to Reproduce were quite important. When investigating the possible failure, they might pass with a similar set of parameters, but only fail with the exact parameters you used.

RESTful Testing with Stripe: Using UriBuilder, HttpGet and other Apache HttpComponents

This post is fourth in a series of six. Need to go back to the beginning?

Now that we built a skeleton framework to test using the Stripe REST API, storing and retrieving the API Key, we can perform actions. We are going to:

• Create a method called getListOfCharges in our StripeUtils class, where we can pass in how many charges we wish to retrieve. 
• Create a data object to hold all the information we retrieve.
• Add functionality that turns the JSON object we get back, and add all information into the data object we created, using Google's GSON library.

What Our Framework Will Look Like

By the end of this blog post, our automation framework will look like:

RESTful Testing with Stripe: Storing API Keys in properties files and initial setup of StripeUtils

This post is third in a series of six. Need to go back to the beginning?

So far we covered why we should incorporate tests other than UI tests into our automation test suite. We gave a brief background on RESTful APIs. And we showed how to interact with the Stripe API through GET methods with HTTPS and POST methods with cURL.

Now, we can start writing code to interact with Stripe! We are going to:

• Store the Stripe API Key in a properties file, pretending that the general purpose key is actually two different keys: One for the US and one for Canada.
• Write a method to Load the Properties
• Create a basic Stripe Utilities that forces the user to select which country we are using. Using that information the proper API key is loaded. 
• Start writing a test class containing tests that confirm Stripe Utilities can only be instantiated if and only if the country is either US or Canada. 

What Our Framework Will Look Like

Subscribe to Adventures in Automation!

Want the latest updates for Adventures in Automation? Subscribe to this blog!

Adventures in Automation has been set up with Google's Feedburner, a web feed management provider. Whether you use MyYahoo, Feedly, Netvibes, SubToMe, you can subscribe to the blog's RSS feed. If you wish, you can subscribe via Email, and get blog posts delivered directly to your inbox.


  Subscribe to Blog:

• Via RSS Feed
• Via Email

RESTful Testing with Stripe: Interacting with Stripe using HTTPS and cURL

This post is second in a series of six. Need to go back to the beginning?

With our last couple of blog post, we talked about how automation needs to be more than simply browser tests, and we covered the early history of RESTful APIs. Before diving into writing a framework from which we can build automated API tests, I wanted to go over their basic interactions.

Interacting with a RESTful API such as Stripe's is as simple as interacting with a web page:

• GET Methods, such as what automatically happens when you go to a website like http://www.tjmaher.com/ ... Your browser accesses the HTML code returned, and interprets it as a web page. You are getting information from the endpoint. 
• POST Methods, such as when you fill out a form on the web or send data such as a Comment. You are sending data to the endpoint. 

We will be interacting in a rudimentary way with RESTful API's such as Stripe:

• To GET, we will be using simple HTTPS calls
• To POST, we will be using a program called cURL.

RESTful Testing with Stripe: Brief introduction to REST APIs

Before launching into a discussion how to test REST APIs such as Stripe's API used to process payments, I wanted to take a step back and talk about what they are and their early history.

With the RESTful API webservice, software developers allow web apps to interact with their software products as easily as you and I interact with a web page.

• GET Methods: To access Adventures in Automation, your browser made an HTTP Request to the web server at http://www.tjmaher.com/, which in turn served you the HTML code that your browser interpreted as a web page. 
• POST Methods: When you enter a message into the Comments textbox at the bottom of this page, then hit the "SHARE" button, the information entered is posted to the web server for processing. 

RESTful APIs are quite common. Fitbit has one. Amazon has a whole suite of them.  Even Boston's subway system, the MBTA has, one. But where did this idea come from? And what is an API?

"API (application program interface) is a set of routines, protocols, and tools for building software applications. The API specifies how software components should interact and APIs are used when programming graphical user interface (GUI) components. A good API makes it easier to develop a program by providing all the building blocks. A programmer then puts the blocks together".
- Webopedia

Coming up: RESTful Testing: How to work with RESTful API's using Apache's HTTPComponents and Java

The next series of blog posts will cover my latest project as an automation developer at Fitbit-Boston: Working with RESTful APIs, such as the one Stripe uses to process credit card transactions. Stripe graciously provides the general public a general use key to access their services. Topics covered:

• Walking manual QA Engineers -- who may have a bit of Java programming experience -- through setting up their development environment.
• Introduction and a brief history of RESTful APIs.
• Introduction to the Stripe API and walkthrough of their excellent documentation.
• How to interact with Stripe through Apache's HTTP Components such as HTTP Client, HTTP Post, HTTPGet, and URI Builder and Java.

I covered in my blog about how at work we were having conversations about Testing Beyond the UI: The Testing Pyramid. The work that I am doing is the next step in that process.

Please note: I've only been an automation developer for a bit less than a year, and I have only been working with HTTP Components for a few weeks, which makes me this all brand-new to me, too. That is why I am attempting this project: By forcing myself to explain what I have been doing, it will deepen my knowledge.

I was wondering, if you are more experienced that I, if you could do a code review when I am finished? I will be publishing working code on my GitHub account. Feel free to add any comments or constructive criticism in the Comments section at the bottom of the page.

These blog posts will be starting this Tuesday, and will be published every Tuesday and Thursday until the project is complete. Subscribe to this Blog to get the latest posts via email.

Thank you for stopping by!

Happy Testing!

NEXT: Intro to REST APIs

RESTful Testing with Stripe:

• Introduction
• Part One: Intro to REST APIs
• Part Two: Interacting with Stripe using HTTPS and cURL
• Part Three: API Keys, Property files, and Initial Setup
• Part Four: UriBuilder, HttpGet and other Apache HttpComponents
• Part Five: From JSON to Object: HttpEntity and GSON
• Source Code: GitHub, T.J. Maher

-T.J. Maher

 Sr. QA Engineer, Fitbit
 Boston, MA

// Automated tester for [ 11 ] months and counting!

Please note: 'Adventures in Automation' is a personal blog about automated testing. It is not an official blog of Fitbit.com. 

Testing Beyond the UI: The Testing Pyramid

Problems with UI Tests

We've been using Selenium WebDriver with Java to write automated browser tests for our eCommerce application ever since the new Fitbit-Boston was formed two years ago.

We have tests for our web application emulating how online customers purchase goods, how customer service agents place orders, such as "Create a standard order containing a year long FitStar subscription and a Fitbit Blaze, with a billing address in the US and a shipping address in Canada, with overnight shipping, paying with a Discover Card".

New Home for Adventures in Automation!

Adventures in Automation has a new home! 

 The new domain is http://www.tjmaher.com. The Blogspot domain was getting a bit unwieldy.

 First time here? Check out last week's post: Adventures in Automation is One Year Old!

Thoughts on the Second Annual 'State of Testing' Survey Results released by Sauce Labs

What is the relationship at your company between DEV and QA like:

• Artist and Art Critic?
• Or Writer and Copyeditor?

According to Sauce Labs' Second Annual 'State of Testing Survey' released a few days ago, testers are more than likely to find the latter instead of the former.

Why? In a word: Agile.