Contribution Guide

Thank you very much for contributing to this project!

Code Changes

1. Fork the repo, create a feature branch & name that feature branch appropriately. For e.g. if you are going to add rotation support for iphone, name the branch something like "iphone-rotation". Please do not make changes in your master branch. Make all your changes in the work branch & get it up-to-date with the upstream before you submit a pull request.
2. Please write unit tests for the code that you're adding or modifying. You don't have to create new mock recordings. Also make sure all the unit tests pass with live server before creating a pull request. The first thing we will do is run against our existing unit tests & they need to pass, otherwise we will simply reject the pull request until you fix the code.
3. Also, please update the relevant POD for the changes you're making.

Integration Tests & Getting Travis CI to pass

In regular instances you should be running the tests against the mocked recording, which are stored in t/mock-recordings. If you're adding tests, or changing the test files, we'll need to make new recordings.

For TravisCI in particular, it uses the Linux recordings, so if you only update Windows or Mac ones, the Travis run will fail. If you have docker, there's a docker-enabled shell script that regenerates the recordings either for all of the test suites, or for a single test file:

$ t/bin/docker-record-linux t/convenience.t

POD Changes

1. Please follow the existing structure that we use. For every method, please include proper Description, Input, Output and Usage (example code).

Without Dist::Zilla

This module is managed with Dist::Zilla, but if you don't want or have Dist::Zilla, you can still use prove to run the tests:

$ prove -l
$ prove -l t/00-load.t

For more information about contributing without Dist:Zilla, see the excellent CONTRIBUTING documents by dagolden and karenetheridge. Feel free to reach out on the issue tracker here with specific S::R::D questions!