|
1 | 1 | # Contributing to Prebid.js
|
2 |
| -Thank you for taking the time to contribute to Prebid.js! |
| 2 | +Contributions are always welcome. To contribute, [fork](https://help.github.com/articles/fork-a-repo/) Prebid.js, commit your changes, and [open a pull request](https://help.github.com/articles/using-pull-requests/). |
3 | 3 |
|
4 | 4 | ## Pull Requests
|
5 |
| -Please make sure that pull requests are scoped to one change, and that any added or changed code includes tests with greater than 80% code coverage. See [Testing Prebid.js](http://prebid.org/dev-docs/testing-prebid.html) for help on writing tests. |
| 5 | +Please make sure that pull requests are scoped to one change, and that any added or changed code includes tests with greater than 80% code coverage. See [Testing Prebid.js](#testing-prebidjs) for help on writing tests. |
6 | 6 |
|
7 | 7 | ## Issues
|
8 | 8 | [prebid.org](http://prebid.org/) contains documentation that may help answer questions you have about using Prebid.js. If you can't find the answer there, try searching for a similar issue on the [issues page](https://github.com/prebid/Prebid.js/issues). If you don't find an answer there, [open a new issue](https://github.com/prebid/Prebid.js/issues/new).
|
9 | 9 |
|
10 | 10 | ## Documentation
|
11 | 11 | If you have a documentation issue or pull request, please open a ticket or PR in the [documentation repository](https://github.com/prebid/prebid.github.io).
|
| 12 | + |
| 13 | +## Testing Prebid.js |
| 14 | +Pull requests to the Prebid.js library will need to include tests with greater than 80% code coverage for any changed/added code before they can be merged into master. |
| 15 | + |
| 16 | +This section describes how to test code in the Prebid.js repository to help prepare your pull request. |
| 17 | + |
| 18 | +### Writing tests |
| 19 | +When you are adding code to Prebid.js, or modifying code that isn't covered by an existing test, test the code according to these guidelines: |
| 20 | + |
| 21 | +- If the module you are working on is already partially tested by a file within the `test` directory, add tests to that file |
| 22 | +- If the module does not have any tests, create a new test file |
| 23 | +- Group tests in a `describe` block |
| 24 | +- Test individual units of code within an `it` block |
| 25 | +- Within an `it` block, it may be helpful to use the "Arrange-Act-Assert" pattern |
| 26 | + - _Arrange_: set up necessary preconditions and inputs |
| 27 | + - e.g., creating objects, spies, etc. |
| 28 | + - _Act_: call or act on the unit under test |
| 29 | + - e.g., call the function you are testing with the parameters you set up |
| 30 | + - _Assert_: check that the expected results have occurred |
| 31 | + - e.g., use Chai assertions to check that the expected output is equal to the actual output |
| 32 | +- Test the public interface, not the internal implementation |
| 33 | +- If using global `pbjs` data structures in your test, take care to not completely overwrite them with your own data as that may affect other tests relying on those structures, e.g.: |
| 34 | + - **OK**: `pbjs._bidsRequested.push(bidderRequestObject);` |
| 35 | + - **NOT OK**: `pbjs._bidsRequested = [bidderRequestObject];` |
| 36 | +- If you need to check `adloader.loadScript` in a test, use a `stub` rather than a `spy`. `spy`s trigger a network call which can result in a `script error` and cause unrelated unit tests to fail. `stub`s will let you gather information about the `adloader.loadScript` call without affecting external resources |
| 37 | +- When writing tests you may use ES2015 syntax if desired |
| 38 | + |
| 39 | +### Running tests |
| 40 | +After checking out the Prebid.js repository and installing dev dependencies with `npm install`, use the following commands to run tests as you are working on code: |
| 41 | + |
| 42 | +- `gulp test` will run the test suite once (`npm test` is aliased to call `gulp test`) |
| 43 | +- `gulp serve` will run tests once and stay open, re-running tests whenever a file in the `src` or `test` directory is modified |
| 44 | + |
| 45 | +### Checking results and code coverage |
| 46 | +Check the test results using these guidelines: |
| 47 | + |
| 48 | +- Look at the total number of tests run, passed, and failed in the shell window. |
| 49 | +- If all tests are passing, great. |
| 50 | +- Otherwise look for errors printed in the console for a description of the failing test. |
| 51 | +- You may need to iterate on your code or tests until all tests are passing. |
| 52 | +- Make sure existing tests still pass. |
| 53 | +- There is a table below the testing report that shows code coverage percentage, for each file under the `src` directory. |
| 54 | +- Each time you run tests, a code coverage report is generated in `build/coverage/lcov/lcov-report/index.html`. |
| 55 | +- This is a static HTML page that you can load in your browser. |
| 56 | +- On that page, navigate to the file you are testing to see which lines are being tested. |
| 57 | +- Red indicates that a line isn't covered by a test. |
| 58 | +- Gray indicates a line that doesn't need coverage, such as a comment or blank line. |
| 59 | +- Green indicates a line that is covered by tests. |
| 60 | +- The code you have added or modified must have greater than 80% coverage to be accepted. |
| 61 | + |
| 62 | +### Examples |
| 63 | +Prebid.js already has lots of tests. Read them to see how Prebid.js is tested, and for inspiration: |
| 64 | + |
| 65 | +- Look in `test/spec` and its subdirectories |
| 66 | +- Tests for bidder adaptors are located in `test/spec/adapters` |
| 67 | + |
| 68 | +A test module might have the following general structure: |
| 69 | + |
| 70 | +```JavaScript |
| 71 | +// import or require modules necessary for the test, e.g.: |
| 72 | +import { expect } from 'chai'; // may prefer 'assert' in place of 'expect' |
| 73 | +import adapter from 'src/adapters/<adapter>'; |
| 74 | + |
| 75 | +describe('<Adapter>', () => { |
| 76 | + it('<description of unit or feature being tested>', () => { |
| 77 | + // Arrange - set up preconditions and inputs |
| 78 | + // Act - call or act on the code under test |
| 79 | + // Assert - use chai to check that expected results have occurred |
| 80 | + }); |
| 81 | + |
| 82 | + // Add other `describe` or `it` blocks as necessary |
| 83 | +}); |
| 84 | +``` |
| 85 | + |
| 86 | +### Resources |
| 87 | +The Prebid.js testing stack contains some of the following tools. It may be helpful to consult their documentation during the testing process. |
| 88 | + |
| 89 | +- [Mocha - test framework](http://mochajs.org/) |
| 90 | +- [Chai - BDD/TDD assertion library](http://chaijs.com/) |
| 91 | +- [Sinon - spy, stub, and mock library](http://sinonjs.org/) |
0 commit comments