Travis CI allows you to run multiple concurrent jobs as part of the same CI build. They even allow for up to 200 parallel jobs for open source projects (the same for private repositories). You can leverage that using Travis build matrix feature to run your project way faster by splitting tests into many smaller jobs that will run a subset of your test suite.

Travis CI

How build matrix feature works?

Build matrix feature allows to automatically create a matrix of all possible combinations of language and environment dependent set of configuration options. For instance, when you want to test your project on 2 different programming language versions and with 2 different browsers then Travis would generate 4 parallel jobs running your tests for each programming language and browser.

Split tests across parallel jobs

We could use build matrix feature to split tests by adding to your project Knapsack Pro that will split your Ruby or Javascript tests automatically across parallel jobs in a way that all concurrent jobs would run subset of test suite and finish work in similar time so you would get the result of your test suite passing or not as fast as possible without waiting for the slowest job.

How to run Ruby tests on parallel jobs with knapsack_pro ruby gem:

# .travis.yml
script:
  # Step for RSpec
  - "bundle exec rake knapsack_pro:rspec"

  # Step for Cucumber
  - "bundle exec rake knapsack_pro:cucumber"

  # Step for Minitest
  - "bundle exec rake knapsack_pro:minitest"

  # Step for test-unit
  - "bundle exec rake knapsack_pro:test_unit"

  # Step for Spinach
  - "bundle exec rake knapsack_pro:spinach"

env:
  global:
    # tokens should be set in travis settings in web interface to avoid expose tokens in build logs
    - KNAPSACK_PRO_TEST_SUITE_TOKEN_RSPEC=rspec-token
    - KNAPSACK_PRO_TEST_SUITE_TOKEN_CUCUMBER=cucumber-token
    - KNAPSACK_PRO_TEST_SUITE_TOKEN_MINITEST=minitest-token
    - KNAPSACK_PRO_TEST_SUITE_TOKEN_TEST_UNIT=test-unit-token
    - KNAPSACK_PRO_TEST_SUITE_TOKEN_SPINACH=spinach-token

    - KNAPSACK_PRO_CI_NODE_TOTAL=2
  jobs:
    - KNAPSACK_PRO_CI_NODE_INDEX=0
    - KNAPSACK_PRO_CI_NODE_INDEX=1

How to run Cypress tests in JavaScript on concurrent jobs with @knapsack-pro/cypress:

# .travis.yml
script:
  - "$(npm bin)/knapsack-pro-cypress"

env:
  global:
    - KNAPSACK_PRO_CI_NODE_TOTAL=2
    # allows to be able to retry failed tests on one of parallel job (CI node)
    - KNAPSACK_PRO_FIXED_QUEUE_SPLIT=true

  jobs:
    - KNAPSACK_PRO_CI_NODE_INDEX=0
    - KNAPSACK_PRO_CI_NODE_INDEX=1

By doing test suite split in a dynamic way across Travis parallel jobs we save more time and keep our CI build fast. I also call parallel jobs as CI nodes because they are part of a single CI build. Here on the video, I describe a few more problems that can be solved with dynamic test suite split.

Travis CI build matrix in action

If you would like to see how Knapsack Pro helps split tests across parallel jobs you can check open source project Consul - Open Government and E-Participation Web Software. There is a list of CI builds for Consul.

Summary

If you would like to learn more about testing with Knapsack Pro you can check other articles on our blog like testing with Cypress test runner.

In case you are contemplating using Travis CI, then this comparison of Travis CI with other solutions can be helpful to you. The comparison of Travis to Github Actions garners the most interest. Other popular pages include Travis vs AppVeyor and Travis vs Bitbucket Pipelines.