Jordan Automates Builds and Testing with Travis-CI

Demo Code Here

I talked a lot about unit testing last week. I really feel that unit testing is a critical part of maintaining code. It helps you have confidence that the changes you make when you add any feature or fix any bug has probably broken existing functionality. This allows you to develop quicker since you can spend less time on manual testing.

This is me, changing code in production without good tests.

I have scripts that I use in production that are depended on daily. I have some testing around their functionality but it’s still not as extensive as I would like. So I feel the stress of each change. I know how easy it is to cause a regression and break code. An easy way to gauge the quality of your tests is the stress you feel when you deploy changes.

Because testing is so important, it’s important that I get quick feedback when my changes have broken my tests. That is the goal with this post. There are three critical parts with using tests:

  • Your tests should run automatically on any kind of push
  • Failing tests should prevent any deploys. This forces you to fix the tests (or if you are crazy, remove them) before continuing
  • You should get quick feedback when it fails. Slack notification, email, something that informs you of the failure quickly.

I used Travis-CI with a Github repository for this example. I’ve also used Bitbucket’s pipelines and it also works really well. It’s very simple once it’s all set up. It took me a bit of research to get it into that state, though. This assumes you have a Github account. This will work with both private and public repositories.

Travis-CI’s home page

First step is to go to Travis-CI‘s site and sign in with Github. I can’t remember exactly what it is like for a fresh sign in but I would guess navigating to the dashboard looks something like this except with “Active Repositories” empty.

Travis-CI’s dashboard

Now we just add the file that will trigger the build within Travis-CI, the .travis.yml file. It sits in the root of your project and a node one looks like this.

language: node_js
node_js:
 - "node"
before_script:
 - npm install

That’s it. Super simple. By default it’s going to try and run your npm test script. I made sure this was the case by testing a gibberish test script and watching the results.


mochadasdsfa: not found ??

Because I have additional packages (I think that most projects would have additional packages), I added the:

before_script:
  - npm install

This ensures that everything will be installed before it runs. Otherwise it would most certainly fail since it doesn’t have the test runners and framework installed.

One final note that changed how I set up the project. Previously I was storing my credentials in a config file that I just .gitignored. If anyone else was to use the project, I had an explanation in the readme explaining that they would need to change the sample file name to the actual file name.

Well, that fails with Travis-CI because when it runs the test script, it does a build and when the Typescript attempts to transpile it notices the missing required file. So I changed over to using the dotenv package which allowed me to use a .env file that did pretty much the same thing.

Now, we would just set the environmental variables in Travis-CI by going to the settings section of our repository in Travis-CI and adding the ones we need; email and password in this case.

Travis-CI environmental variables

And finally, you can easily get the build status image by just clicking the image in Travis-CI. It’ll then give you an option to get the markdown version. You just copy this and paste it into your readme.md file wherever you want (typically it’s in the title).

TA-DA! Done. Travis-CI will notify you if a build fails and then when the build is fixed. It really is a great tool to ensure your automated tests are running regularly.

Leave a Reply

Your email address will not be published. Required fields are marked *