When putting code on github, especially code we want to share, it’s important not only to have tests, but have tests that our code passes. If the code doesn’t pass our tests then, at least according to our tests, the code is broken.
But if we are downloading code from github, say a ruby gem, how can we know if the code works?
Well, one great way is to look at the build-passing tags, such as the one on the bottom far left here for Nokogiri:
And here on the bottom far left for Pry
They, like a huge number of other repositories, use a program called Travis CI, and here we’ll explore how to use it and set it up.
I’m assuming here that you are familiar with github, have an account, and know basic git commands.
First, go to the travis ci website and press sign up. If you’re signed in to github when you press that, then it literally signs you up automatically and syncs your github account
If we go to our profile page, we can see a list of all our public repositories (private ones can only be seen with a paid account, I believe), and switches which default to off, signaled grey X’s.
To active the one we want, click the sliding button, which will turn green and indicate that our repository will be tracked by travis.
How linked is this with github? If you press on the repository name, it opens the repository on github just like that!
The first step in making a repository respond to travis ci is to add a file to the root directory of the project called .travis.yml and push it up to github.
For the repository we will test this on, I added a primitive test to a gem repo called alphabet_soup.
Inside of the .travis.yml file, you have to put a few lines of code. See here for full detailed documentation. For most users of ruby, however, it’s enough to put in a few lines of code, such as: language: ruby #the language we’re using rvm: - 2.2.3 # the version of ruby we’re using
Once this file is all set up and our tests are written in our spec or other testing directories, we can push up to github.
Then, on the travis website, we should see the repository we added come up on the left sidebar. When we click on it, it now shows a record for each time we pushed to the repository, with a green light for when we passed the tests in the spec folder and red for when the tests failed.
Not only that, but it shows a screenshot of the tests being passed or failed!
Then on the top right of that same page, we finally see our goal, the option to add the build pass button to our github repository. Note: In the screenshot above, taken right after I had linked to travis and pushed to github (with passing tests) for the first time, the icon has not yet updated and turned green. It will take a few minutes.
If we are using a readme.md, then select the markdown option and copy paste the resulting url to the top line of the readme file. Push that to github, and we’re done. The tag is added!
If my next build fails, then the gem will turn red and announce it to the world so that no one downloads the broken code. It’s a great way to tell the world that they should stay away from our broken code, or that it’s passing all the tests we set it and, hopefully, works!
Keep in mind that this on its own doesn’t signal whether our tests are comprehensive. For example, if we make a simple test that passes if, say 1 + 1 = 2, and that was the only test, then our light would still turn green. That’s even though the test is completely useless. We can test the thoroughness of our code through another program that works on top of and through travis ci, called Coveralls. But let’s leave that for another time.
