Case Study: Logistics

Real-world examples of automancery at companies like yours

“Most people think Cucumber is for running tests, but it’s actually not.” “…Well what IS it for?” “I’m glad you asked.”

World Wide Technology is headquartered right here in St. Louis, and is the leading provider of a lot of equipment. To be that leading provider, they have to be crazy good at logistics. To be crazy good at logistics, they have to write some good quality software. To ensure quality, that software has to be tested.


That’s where we come in. And that brings us up to the day of the initial meeting.

We were with the QA manager, the QA leads, and the QA project manager. They were explaining how, with 20+ teams spread across two buildings in STL and distributed all over the world as well, it’s hard to have a good solution that fits everybody. Each team had a network of lots of APIs–programs that simply create, read, update and delete data to process work quickly–and no two teams were alike. They all had their own standards and expertise.

“What we’re needing is something that lets anybody write a test quickly. We’ve been looking at all kinds of technologies and really like what Cucumber brings to the table.”

Side note: Cucumber is a popular testing framework that lets you write tests in plain English. We’ll see an example a bit further down.

The challenge was: since everybody had wildly different APIs, goals and processes, it’d be a mess if the solution exposed all that wild messy stuff to every team. We’ve seen that happen, and it results in a lot of confusion.

But there was a bigger challenge too: they were thinking of Cucumber as solely a testing tool. It’s good at testing, great even, but thinking of it solely as a testing tool limits what all you can do with it.

So I said, “Most people think Cucumber is for running tests, but it’s not.

And there was a pregnant pause.

Got ’em. That’s exactly what I was hoping for.

…well what IS it for?” Glad you asked.

Cucumber’s really just an “English-to-whatever” converter

Don’t get me wrong, Cucumber’s excellent at running tests. And it lets people write those tests in plain English which is awesome.

When it reads through that plain English test (called a Feature File) it says, “Ok, based on this phrase, what actual piece of code am I supposed to go run?” That code’s usually written by a developer once, but it can be run multiple times by people who aren’t developers. Very cool.

But often times, people write a really complex, unique piece of code that actually does a whole lot of work. That means that one piece of code can’t really be reused much, and it’s more likely that a developer would have to keep writing more pieces of code. That slows down the testing process and adds more chance for error. Very not cool.

“Instead,” I offered, “let’s think of this in terms of what’s really happening when we run a test.”

When we send data to (and receive data from) an API, it generally looks the same. Here’s an example payload:

# we'll call this payload EmployeeRecord.json

That payload would go to, say, an API that gives back information about an employee. If you send that you might expect a response like this:


So instead of writing a single piece of code that tests for that condition, we break it up into smaller pieces:

  • A piece of code that can read in a sample payload
  • A piece of code that can modify a field in that payload
  • A piece of code that sends the payload
  • A piece of code that reads a field in a response payload
  • A piece of code that compares a field to an expected value

Once those pieces of code are written, tests can be written like this:

Given we have an "EmployeeRecord" payload   
And the "firstName" is set to "John"        
And the "lastName" is set to "Jones"
And the "hireDate" is set to "2020-05-16"
And the "employeeStatus" is set to "FT"
And we send the payload to the "EmployeeLookup" service
Then the "EmployeeId" should be "112233"

The result is: anybody on a particular team should be able to write tests like that. I’d take care of writing the code underneath that they wouldn’t have to worry about, and they can focus on taking their domain knowledge and putting it in this format. It’d work for any team, any API, and give good visibility into what’s being tested so that the higher ups can see and understand as well.

We got the deal.

Here’s how we socialized the solution

To get this to take effect, we couldn’t be responsible for building out every test for every team. That’d make the project huge. But that’s why we went with doing the solution this way.

World Wide Technology prides itself on hiring innovative rule breakers. There were plenty of people in the company that loved doing Cool Things(tm), and we used that to our advantage. Almost every team had at least one person that we call an “Evangelist”. These are people that learn quickly, and get so foamed up about the Cool Things(tm) that they just gotta share with others.

We find those people, train them, and then bring them into group sessions where they can share what they know and answer questions.

But there was another unique opportunity: a monthly symposium.

The QA manager mentioned this was coming up and said, “If we can’t make it to this one, that’s fine. We can make it to the next one.”

And I was like, “Dude no we gotta make this! This would be a really cool way to share what we’re doing on the QA team because this can help a lot of people. But we have to come up with a name.”

We talked back and forth and needed something neat. Snappy. Memorable. But also something that described succinctly what this new framework did.

We settled on the name “unify”. All lower case of course.

Then I put together a presentation and a small demonstration, showing how easy it was to create and modify tests. And it ended up there were 3 Evangelists in the audience who helped spread the solution around even further. Big win.

They’re still using it today.

In the summer months, WWT brought in some interns, and even they were trained on how to use unify, and went about automating tests for different teams. It was great experience for them and brought some much-needed work to teams swamped with getting their products out the door.

From what I’ve heard, unify is still in use today and is saving hundreds of hours in test development, debugging and deployment every year.

Automation doesn’t have to be complex. We’d much rather craft a simple solution that works so well, people might wonder why things are so easy now. This is such a simple approach to testing APIs that we’ve been doing it for all of our clients that have an API-heavy offering, and it’s worked great even outside of Logistics.

Would this approach help you too? Let’s get some time to chat.