If you’re reading this I’m going to assume that you’re human, and not some bot scraping the internet looking for it’s next target.

The majority of the time a human is going to be reading your automated test too.

So why aren’t we writing test for the humans that will be reading it?

First let me just say, code written for an automation framework is different then code written for your application.

Might sound obvious but this is confused so often that I have to bring it up.

Yes there are similarities but things are more important on one side compared to the other.

Readability is definitely one of them.

Why Human Readable Tests Matter

Here’s the thing, you’re going to be looking at your automation code A LOT!

No seriously, you’ll be reviewing looking and reading lines of code 5, 10, 20 times more then production code.

Do yourself a favor and make sure that it’s human readable.

Test fail & when they do the first questions is… “Was the failure because of a bug in the application?”

Being able to read the stack trace find the failure and understand what’s going on just by reading the tests saves time. This adds to the startups bottom line, and helps you grow more quickly.

Alright let me get off my soapbox.

Basic Human Readable Test Case Example

Just to make things a little more concrete here’s an example

Let’s say you have a test like this:

Create a new account, pick an on-sale item, add it to your cart and check out using CoinBase. Verify that we hit the order success page.

We might write an automated test like this:

java
UsersWorkflow.CreateNewUser();
LoginPage.LoginWithLastCreatedUser();
SaleItemsPage.AddAnyToCart();
CartWorkflow.CheckoutUsingCoinBase();
Assert.True(CheckoutSuccessPage.IsLoaded());

Key Points From Example Human Readable Test Case

• Written in “business language.” As close to the language an end user or business person would use to describe the test.
• Methods calls does the heavy lifting.
• No declared variables. Humans aren’t really good at holding large amounts data sets. Tests should be simple. Let the framework remember the state.
• Methods don’t care about trivial paramaters. If you don’t care about variation, eliminate it. What we really care about is checking that CoinBase was used.
• Static clases. Who wants to “new-up” objects, & worry about constructors? Most human will choose the path of least resistance. Bad for production code, but just fine for test API’s. Makes it easier for tester to write test.
• Assert something at the end. If you’re not asserting you’re not testing.

By working this way, you ensure a reduction in the total lines code and complexity of your tests by as much as possible. This all goes a long way to making things Human Readable.