We worked on testing in headless browser, also we worked on saucelabs in order to make our tests on several browsers with a command line. All this thanks to karma, mocha, and many others. This time is the one say thanks to Travis and Github.
Github is a sharing and publishing service that works with descentralized repositories. You can actually fork, create repositories, and work with other people.
Travis is a service to make continuous integration to build and test projects hosted in Github.
So lets face what we want now and thats our objective. We want to give our thoughts through Github sharing with other people what we need probably some of this persons will be helping us. But dealing with so many contributions without any order can be a counter back to the happy ending of our project.
We need to share our thoughts with proves that it works, in a organized way so each contribution will actually give one more brick to the great house we are making.
So we need each contributor to work with tests, those tests will run every time the code goes to Github, thats the place we make our integration by giving a stable system. And also those tests will be running in different devices thanks to saucelabs.
Now who is the one to be running all this tests, well actually there are several options, Bamboo, Travis... Now we will look at Travis-ci.
And there is one more I added, coveralls. I recommend adding it too, you just need to login coveralls, and just add the repository you need to get a badge on the coverage you have for that project. We will go further on coverall soon.
This is just a flavour, I like to run those things I need with gulp for the day by day programming, and for building a version for each environment, production, testing, develop, with jshint / jscs, testing etc... But there are some things that needs to run in a post integration matter that are very expensive to be running all the time. So those things can actually be done by travis, saucelabs.
Defining some environment variables
We need travis to run some of our things.
First we need to create an account on travis. Then we just select the Github project we want to make Continuous Integration.
Second create a file .travis.yml this will be the one say travis what to do.
Then we need to set some environment variables to Travis. This way some credentials will be available when travis runs our configuration.
But we don't want those credentials to be online for every body. So lets encrypt them, to do so I recommend going to travis encryption keys.
At the moment of this writing I already have a .travis.yml, and just runned the following command.
$ travis encrypt SAUCE_USERNAME=[YOUR USER NAME] $ travis encrypt SAUCE_ACCESS_KEY=[YOUR USER NAME]
So after doing this you will find the following code in your .travis.yml
Saying what to do to Travis
So I started defining some tasks that will actually run for my project. Each project has his own configuration, this is just one more option:
We can see that there are our secure encryption for saucelabs. That we are saying to travis we will connect to saucelabs.
We are saying that we need to get phantomjs-2.0.0 from a wget and then we are extracting in order to implement this library, this is because of this issue
In the script we are going to run gulp task for production. This is a task runner for this particular project, you can have whatever you need in order to create that version of the product you are going to have.
After the success on our running we will run our continuous integration, and coveralls
npm run ci command will run our tests for local and for saucelabs.
You can see this line install: travis_retry npm install is because some times when running npm install with travis failed because of .lock files for where present in the moment I runned with travis. This sometimes happens because of sharing some resources and folders, so travis can try again installing this dependencies that may be are shared with npm in a race condition problem. Remember all this is for free, so this is the workaround I found for this problem.
As we said before in browser testing, the coverage produces a lcov.info file that is the information we need to create reports of coverage.
Saying this, the lcov.info will go to the coveralls service and coveralls will create our badge for us for this repository.
After so much work we can see the following results over travis:
After running all the gulp tasks, the end of travis report is:
We are happy to see that travis says everything goes alright
And in coveralls we can see the following:
So now we know there is a lot to do! only 40% of my code is covered.
We can inform in Github to everyone how this project is going.
We have created a complete environment for testing and working with Github with Continuous Integration and more. Actually we are not running just tests to say we are covered, we are running those tests to see how they work on different browsers with saucelabs. This is great.
We are informing with reports how much coverage we have in our code. And also we are saying that our build is successful.
This is awesome, but we need one more thing to make things going in a good contribution matter. We need to be organized in those contributions. I am actually working with git in a team following this strategy of branches, it is great.
Finally why not adding performance test to the end of this chain? Well actually I invite you to see the post about page speed insights. You could add some performance automation if you want too.