In our previous entry of the What Is CI series, we covered some of the basic elements of what CI is and does, and how it can benefit you. Today, we’re going to dive a bit deeper into unit testing and deployment - two things that Travis CI can help expediate and remedy, while helping you keep focusing on the work at hand.

What are Unit Tests, and what do they do?

When you develop an application, a fair chunk of time will simply go towards testing and ensuring that it passes all your tests. Initially, it’s usually easy to keep up with all the tests that you need to run and you do so rather naturally simply as you develop. This is especially true when testing the new features that are added as they come, since you want to get very hands on with them all the time.

But what about when the project grows, and a minute or so is no longer enough to test everything? Sure, you’ll be testing the new things that are added rigorously, no doubt, but what about the older things? The things that you tested ages ago and you’re relying on? Then, out of the blue, a feature no longer works, and you have to start digging through debugging and all sorts of tools to get to the bottom of it. Turns out that changing that bit of JSON had farther reaching consequences than they should have…

This is where Unit Testing comes in. Simply put, they are tests that you design and run. They run against your code and compare the results they get with what you specify that you’re expecting, so you can detect when a change has been made and catch any potential problems early.

This Stack Overflow question has some information on them, and with CI, it’s easier than ever to run them - you simply add them to your .travis.yml file, and you’re all set!

You can find a basic code sample here. If you look at the .travis.yml, you will see the following lines:

script:
  - ruby calculator_test.rb

This specifies that the test will run during the script phase. If this test fails, the build itself will stop, and you will receive an email letting you know. When things run smooth, the build simply completes. When things don’t entirely work? You can see an example of what that looks like here.

Unit tests are a great way to ensure that all parts of your development are working as they should without taking the extensive time to test everything manually constantly. And if implemented with Travis CI, they can run everytime a push is made, or before a merge is done.

Deploying all the things!

So let’s say all your tests come back clean, and everything builds and looks correct. You’re all ready to release this to the public. You start the process you have in mind, be it simple FTP or SSH uploading, or using an application deployment key with your preferred vendor, or anything.

Wouldn’t it be nice that once you have the tests of your choice completed that it deployed itself to wherever you needed it to be? It sure would be, and that’s why we have the option to deploy automatically on success.

Let’s take a look at the basic code sample once more, and the .travis.yml. You’ll see this listed:

deploy:
  - provider: pages # check the site at https://iriberri.github.io/ruby-test-example/
    github_token: $GITHUB_TOKEN
    skip_cleanup: true

What this means is that once it reaches the deploy stage - after the testing we set up above - it will go ahead and deploy straight away to the GitHub pages. As mentioned above, you can see the results here. Notice the $GITHUB_TOKEN - this is what’s called an environment variable and we’ll be discussing those in detail later on.

With the above setup, deployments will happen on any commit that’s pushed through. This might be fine for some users, but generally, you might not want to do that. Perhaps you want your nightly builds pushed to one place and your master builds pushed somewhere else, or you only want to deploy when there’s an upgrade to the ‘master’ branch. Not to worry: you can have both!

Add the following to the bottom:

on:
  branch: master

This will ensure that only changes made to the ‘master’ branch are deployed, and for any other ones (such as the ones you’re working on currently that aren’t ready for live) the deploy step is completely skipped. It will still run unit tests if you’ve specified them, and anything else for that matter.

If you haven’t yet, please feel free to head back on over to our previous entry in the What Is CI series,

You can certainly go more in depth: a lot more in depth, in fact. But if you are just starting out with CI, we hope this is helpful to you. Come the new year, we’ll be continuing to look into how you can use CI to improve your workflow. Until then? Happy building!