How To Automate Your Tests With Travis CI

There are two things we can agree on about testing:

1. It's essential.
2. It's a pain.

Every time you make a code change, you have to check every single regression that's ever occurred, which is tedious enough, even before considering that you also need to make sure you're testing the same things, in the same order, in the same environment, every time, without messing up even once.

It's daunting, right? To quote the old infomercial line: There's got to be a better way!

And there is: Travis CI.

What is Travis CI?

Put simply, it's a thing lets you automate running your tests whenever you make changes. The same exact process gets executed every time, so you don't have to remember a thing. Once you’ve written a configuration file and added it to the base of your project, you're ready to go.

How do I set it up?

Create a .travis.yml file in the root of your project, authorize Travis CI to access your GitHub repos, and then move on with your life.

Your config file can be really simple, as simple as:

language: php

php:
  - 7.1.9

script:
 - phpunit

Pow. What that does is tell the Travis CI server, "Every time a commit is pushed to this repository, or someone opens a pull request against it, run phpunit with PHP 7.1.9 and display the results on the status page."

Obviously, you can do more, much more, but this will work for now.

How do I run it?

This is the best part: once you've created the .travis.yml file, and authenticated with GitHub, it just... runs. No buttons to push, nothing to remember, it's just there, helping you out from now on.

What can I test with it?

Anything you want! At its core, the .travis.yml file is pretty much just a shell script with some bonus features. It:

• sets itself up
• runs the CLI commands you specify in the order you specify
• lets you know the results

Depending on your workflow, you can set up result notifications via email, IRC, Slack, OpsGenie, webhooks, and many other methods.

You can run tests on code written in PHP, Java, Python, Perl, Ruby, Objective-C, Swift, and more. If you have a testing plan right now, you can probably move it to Travis CI and have them run it for you.

What else can I do?

Honestly, it'd be easier to say what you can't do, but with a small amount of additional configuration you can:

• only run certain tests depending on if earlier tests succeeded or failed
• run your tests on macOS instead of Linux
• test a specific branch or commit, and only a specific branch/commit
• test against multiple versions of your chosen programming language, with multiple values for certain environment variables, at the same time

It's really quite flexible.

Normal testing VS Travis CI

Let's compare what you might have to do now to test your code changes, to what life would be like if you used Travis CI.

Here's the standard process:

1. Push a commit to your repository
2. Spin up a VM
3. Install Ubuntu
4. Install PHP
5. Install PHPUnit
6. Install Git
7. Clone your repository
8. Run your tests
9. Note the results
10. Notify people of the results

And here's that same process, using Travis CI:

1. Push a commit to your repository
2. Go get a coffee
3. Maybe a doughnut too
4. Read some news
5. Oh, the tests are done already?

I know which one I'd pick.

Conclusion

Pablo Picasso once said "Computers are useless, they can only give you answers." And that's true. But sometimes the answers are important, like "Did the code change I just committed break any of my 1,043 regression tests?" Automating your tests with Travis CI frees up your time for the important, human-led part of QA: Finding more things to break.

Happy testing!