|
7 | 7 | * The maximum line length for any PHP file is 100 characters, instead of PSR-12's 120 characters. |
8 | 8 | * Comments should be used sparingly. |
9 | 9 | * Empty lines should be used sparingly. |
| 10 | +* No code should call `die()` or `exit()`, instead `UnitySite::die()`. |
10 | 11 |
|
11 | 12 | This repository will automatically check PRs for linting compliance. |
12 | 13 |
|
@@ -56,3 +57,52 @@ Notable users: |
56 | 57 | ### Changes to Dev Environment |
57 | 58 |
|
58 | 59 | Should the default schema of the web portal change, the `ldap/bootstrap.ldif` and `sql/bootstrap.sql` must be updated for the LDAP server and the MySQL server, respectively. |
| 60 | + |
| 61 | +## Testing |
| 62 | + |
| 63 | +Github Actions are used to execute all following tests for all pull requests. |
| 64 | +This means that if you're feeling lazy, you don't have to go out of your way to run tests, you just have to wait a bit longer for Github to do it for you. |
| 65 | + |
| 66 | +### `pre-commit` |
| 67 | + |
| 68 | +We use `pre-commit` for enforcing (and sometimes automatically fixing) the PSR-12 code standard, whitespace discrepancies, syntax validity, secret leak detection, and whatever else can be done quickly. |
| 69 | +`pre-commit` runs automatically every time you commit, assuming you set it up correctly. |
| 70 | +To save time, `pre-commit` only runs on the files with staged changes. |
| 71 | +To run on all files, use `pre-commit run --all-files`. |
| 72 | + |
| 73 | +### `phpunit` |
| 74 | + |
| 75 | +Since this codebase was not written with testing in mind, and this codebase makes extensive use of external resources such as SQL and LDAP, most of our testing does not focus on isolated "units", but high level functionality. |
| 76 | +Our functional tests pretend to make HTTP requests by modifying global variables in the same way that a production webserver would. |
| 77 | +This is preferred over directly calling library code because it helps to test the PHP logic in the webpages themselves, rather than just the internals. |
| 78 | +For example, one functional test would be to set `$_SERVER["REMOTE_USER"]` to authenticate as a user, `require "resources/init.php"` to setup the `$USER` global variable, set `$_POST["key"] = "ssh-rsa ..."` and `require "webroot/panel/account.php"` to make that user enter a new SSH key in the HTML form in the `account.php` page. |
| 79 | +Once a user action has been taken, internal interfaces are used to verify the results. |
| 80 | + |
| 81 | +To run `phpunit`, spawn 2 shells in differnt tabs: |
| 82 | + |
| 83 | +tab 1: |
| 84 | +```shell |
| 85 | +cd ./tools/docker-dev |
| 86 | +./build.sh |
| 87 | +./run.sh |
| 88 | +``` |
| 89 | + |
| 90 | +tab 2: |
| 91 | +``` |
| 92 | +$ container="$(docker container ls | grep web | awk '{print $1}')" |
| 93 | +$ docker exec "$container" -it bash |
| 94 | +> cd /var/www/unity-web |
| 95 | +> ./vendor/bin/phpunit /path/to/tests |
| 96 | +``` |
| 97 | + |
| 98 | +For `/path/to/tests/`, you usually want `./test/functional/` but you can select a specific file to save time when troubleshooting specific tests. |
| 99 | + |
| 100 | +### code coverage |
| 101 | + |
| 102 | +`phpunit` has code coverage built in. |
| 103 | +It recommends the use of "strict code coverage", where every single test explicitly lists what functions it covers. |
| 104 | +That's a lot of work, so instead we accept what phpunit refers to as "risky unintentionally covered code". |
| 105 | +Using [robiningelbrecht/phpunit-coverage-tools](https://github.com/robiningelbrecht/phpunit-coverage-tools), our Github Actions testing will fail if the coverage falls below a certain percentage of lines of code. |
| 106 | +This percentage should be increased over time to just below whatever the current coverage is. |
| 107 | + |
| 108 | +To run a code coverage test, use the same procedure for phpunit but add these arguments: `--coverage-clover="$(mktemp --suffix=.xml)" -d --min-coverage=./coverage.php` |
0 commit comments