Found a bug? Crashed the app? Broken challenge? Found a vulnerability that is not on the Score Board?
Feel free to create an issue or post your ideas in the chat! Pull requests are also highly welcome - please follow the guidelines below to make sure your PR can be merged and doesn't break anything.
This repository is maintained in a simplified Git-Flow fashion: All active development happens on the develop branch while master is used to deploy stable versions to the Heroku demo instance and later create tagged releases from.
Using Git-Flow means that PRs have the highest chance of getting accepted and merged when you open them on the develop branch of your fork. That allows for some post-merge changes by the team without directly compromising the master branch, which is supposed to hold always be in a release-ready state.
There is a full suite containing
- independent unit tests for the client-side code
- integration tests for the server-side API
These tests verify if the normal use cases of the application work. All server-side vulnerabilities are also tested.
npm test
Since v2.7.0 the
npm testscript verifies code complicance with thestandardstyle before running the tests. If PRs deviate from this coding style, they will now immediately fail their build and will not be merged until compliant.
The e2e test suite verifies if all client- and server-side vulnerabilities are exploitable. It passes only when all challenges are solvable on the score board.
npm run protractor
The e2e tests require a working internet connection in order to verify the redirect challenges!
The mutation tests ensure the quality of the unit test suite by making small changes to the code that should cause one or more tests to fail. If none does this "mutated line" is not properly covered by meaningful assertions.
npm run stryker
Currently only the client-side unit tests are covered by mutation tests. The server-side and end-to-end tests are not suitable for mutation testing because they run against a real server instance with dependencies to the database and an internet connection.
During releases the application will be packaged into .zip/.tgz archives for another easy setup method. When you contribute a change that impacts what the application needs to include, make sure you test this manually on your system.
grunt package
Then take the created archive from /dist and follow the steps described above in Packaged Distributions to make sure nothing is broken or missing.
From time to time issues might get a bounty assigned which is paid out to the implementor via the Bountysource platform.
How Bounties work:
- Users fund bounties on open issues or feature requests they want to see addressed.
- Developers create solutions which closes the issue and claim the bounty on Bountysource.
- Backers can accept or reject the claim.
- If accepted, Bountysource pays the bounty to the developer.