My Test Driven Development Journey With Travis CI

A beautiful union of Travis CI and Github — Credits: This awesome medium post

During the course of the Andela’s Bootcamp, I was introduced to a lot of new concepts and tools. There was Istanbul and nyc for test coverage, there were also Mocha and Chai for Unit Testing, I got to interact Coveralls and Code Climate for Test reporting, working with Babel for transpiling ES2015 code to ES5 was pretty amazing. Initially, setting these tools up seemed Herculean and daunting at first as I have never used them before, but having a Growth Mindset helped me accomplish a lot with these tools, from setting up, to integrating them. One day I would write separate articles about my experiences with each of the aforementioned tools.

This post is dedicated to Travis, I purposely decided not to mention Travis among the tools listed in the previous paragraph. For some weird but good reasons, I grew fond of Travis, that I began to personify it a lot. Probably because I was amazed at how flexible Travis was at integrating with the other tools I listed above especially Coveralls and Code Climate or because it was the major arbiter to guaranteeing a successful or failed build.

Before I continue detailing my experience with Travis, I would like us to understand a bit of Test Driven Development (TDD), so we can understand how Travis plays an important role in the entire TDD process.

Continuous Integration

Continuous Integration is the practice of merging in small code changes frequently — rather than merging in a large change at the end of a development cycle. The goal is to build healthier software by developing and testing in smaller increments. — Travis

For someone relatively new to TDD (Someone like me), the idea of crafting software is building a monolithic codebase, jump right in and start building features. From a personal standpoint, building software this way leads to a lot of bottlenecks, fix one bug here and find out that it has caused a bug somewhere else. This is what Continuous Integration seems to eliminate, it proposes the idea of implementing features incrementally and in small changes making bugs easier to track.

Build

A Build is simply a series of tasks/processes defined to be carried out when there is a new change in our repository. For Travis CI, the tasks are defined in a .travis.yml file.

So here’s how Travis CI runs a build

When you run a build, Travis CI clones your GitHub repository into a brand new virtual environment, and carries out a series of tasks to build and test your code. If one or more of those tasks fails, the build is considered broken. If none of the tasks fail, the build is considered passed, and Travis CI can deploy your code to a web server, or application host. — Travis

language: node_js
node_js:
    - "stable"
env:
    global: CC_TEST_REPORTER_ID=Code_Climate_Key
before_script:
    - curl -L https://codeclimate.com/downloads/test-reporter/test-reporter-latest-linux-amd64 > ./cc-test-reporter
    - chmod +x ./cc-test-reporter
    - ./cc-test-reporter before-build
cache:
    directories:
        - "node_modules"
after_success:
    - npm run coverage

So the above snippet is what one of my .travis.yml file looks like. I’d try to summarize each line.

1. We specify the language type as node.js
2. We define our environment variables e.g. I just defined the Code Climate key.
3. We define a task to run before Travis begins running our specified tests. In our example snippet, we are simply asking Travis to setup and prepare Code Climate for code coverage before the tests run. We would be using Mocha and Chai for defining our tests.
4. We specify directories that we want to be cached, for the snippet above, we want Travis to cache the node_modules so it doesn’t always re-install our dependencies on each build. This speeds up our subsequent build processes.
5. We further direct Travis to run another task after our tests are completed, in our snippet, npm coverage sends our test coverage results from Istanbul to Coveralls.

Finally, Travis is integrated with our Git repository. So for each Commit we make (or even a Pull Request) on Github, a build process is triggered and Travis would use the configuration we defined in .travis.yml during the build process. If during the build process our test fails, we have a failed build. On the other hand, if all our tests pass, we have a successful build. We also have instances when our build is errored e.g when there is a timeout.

We’ve seen how Travis seamlessly integrates with a variety of technologies and tools such as Github, Mocha + Chai, Code Climate, Coveralls and Istanbul in a software development process. We could also see how Travis simplifies a complex process just with a simple configuration file.

If you are still wondering why I’m so amazed by Travis, now you know why.