How We’re Using Robots to Test Our Mobile Credit Card Reader

Automating Manual Test Processes

Bart Powers
The Mindbody Dev Report
5 min readMar 21, 2018

--

The Tentacle a.k.a. James Pusher

At MINDBODY, we take testing seriously. And as part of the automation team, it’s our job to figure out ways to automate everything. This project began while we were building an automated UI testing regression suite for our business facing iOS app. After working closely with QA to go over our regression test suite to determine which test cases could be automated or not, we would continually agree that testing our credit card swiper was something that would need to be completed by a manual tester. As an automation engineer, it was hard to accept that this process couldn’t be automated, so we set out to build a robot that could handle the task for us.

The Goal

We wanted to create a machine we could trigger from within our mobile test automation framework, simulating a user swiping a credit card through our mobile credit card reader.

Our mobile credit card reader

The test looks something like this:

  1. Given I am logged in to a site that accepts credit cards
  2. And I have the mobile credit card reader connected
  3. And I add a product to the cart
  4. When I choose the SWIPE CC payment method
  5. And I swipe my credit card
  6. And I sign in the signature field
  7. Then I can complete the sale

We needed to figure out how we could accomplish Step 5 without a manual tester.

Designing the Robot

We discussed a variety of options for robots that could handle this task and spent some time researching online and watching other interesting ideas like this one or this little guy. While these ideas appeared to work, we wanted to build something extremely simple and reliable. All we needed to do was move a credit card forward and back and thought a simple crank could do the trick.

A simple crank animation

Based on the gif above, all we would need to do is connect a credit card to the blue line, stabilize the blue line so it transfers the power in the proper direction, and provide rotational power to the red circle when we want to trigger a swipe. Easy enough — let’s get some parts!

Providing power to rotate the crank comes from a CNC Stepper Motor. This is the strongest stepper motor we could find. Although we had started with a smaller one, it wasn’t strong enough to push the card through the reader. To spin the motor the correct distance and at the proper speed, we wired it to a Stepper Motor Driver and connected that to an Arduino Uno. The motor was so powerful it needed its power supply, which we were able to get here.

Now that we had our rotational power under control, we had to mount the card to a track to transfer the energy in a stable direction. To do that, we purchased a cabinet track and mounted it to a board.

Cabinet track

We picked up the rest of the parts — including an electrical box cover to mount the motor to as well as well as some random nuts, bolts, and plenty of epoxy — from Home Depot.

3D printed arm and credit card holder

Luckily, a co-worker lent us his 3D printer, and we were able to get a custom crank arm and credit card holder printed to fit on the shaft of our stepper motor perfectly. With everything built, it was time to plug it in and write some code to make the thing work.

Without going into too much detail on the backend coding, we set up a node.js server running on the computer that handles our automation and set up a listener on localhost:XXXX/swipe. Since we used a node server, we also used a library on Johnny-Five to tell the Arduino and stepper motor what to do when the corresponding endpoint was requested.

We use XCUITest framework provided by Apple, and once we get to the swipe card screen, we make a call to the http://localhost:XXXX/swipe endpoint and wait for it to complete. Upon completion, it returns a success message, and we can continue our UI test by signing and completing the sale.

Close up. So smooth.

Overall, it turned out to be a great, successful project — and we were able to re-use a lot of the code we’d written in other projects. We also used the robot to stress test our physical credit card readers by running the same test more than 1,000 times to get an average swiper failure rate. The robot definitely saved some manual tester from going insane.

Swipe away!!

We’re Hiring!

Information created by third parties that we may link out to or feature on our site is not endorsed by us and remains the responsibility of such third parties. MINDBODY assumes no responsibility for errors or omissions in the content.

--

--