PrivateBin/tst
2022-10-23 13:09:54 +02:00
..
Data apply StyleCI recommendation 2022-01-22 08:47:34 +01:00
Persistence actually support the short CIDR notation 2022-02-28 16:24:06 +01:00
Bootstrap.php Apply StyleCI fix 2022-02-12 16:41:25 +01:00
ConfigurationTest.php remove configurable dir for traffic & purge limiters 2021-06-08 06:37:27 +02:00
ConfigurationTestGenerator.php remove configurable dir for traffic & purge limiters 2021-06-08 06:37:27 +02:00
ControllerTest.php adding tests for YOURLS functionality 2022-10-23 13:09:54 +02:00
ControllerWithDbTest.php implementing key/value store of Persistance in Database storage 2021-06-09 07:47:40 +02:00
ControllerWithGcsTest.php improving code coverage 2021-06-13 10:44:26 +02:00
FilterTest.php update minimum required PHP version to 5.6 and replace slowEquals() with native hash_equals() function 2020-02-05 19:30:14 +01:00
FormatV2Test.php apply StyleCI patch 2019-05-10 21:45:34 +02:00
I18nTest.php allow for Lojban (jbo) to be the "any" language pick 2022-02-17 20:44:49 +01:00
IconTest adding icon generator comparison test script for reference in #148 2019-06-16 09:16:50 +02:00
JsonApiTest.php adding tests for YOURLS functionality 2022-10-23 13:09:54 +02:00
ModelTest.php clarify use of getDeleteToken() method in unit test 2021-06-16 04:39:24 +02:00
phpunit.xml removing outdated configurations and fix path of phpunit 2020-05-31 15:24:10 +02:00
README.md switching webcrypto library to native node crypto implementation (requires node>=10) 2020-06-01 08:07:25 +02:00
RequestTest.php switching to full JSON API without POST array use, ensure all JSON operations are done with error detection 2019-05-13 22:31:52 +02:00
ViewTest.php allow unit tests to pass 2022-10-23 09:12:31 +02:00
Vizhash16x16Test.php folding Persistance\ServerSalt into Data\Filesystem 2021-06-08 22:01:29 +02:00
YourlsProxyTest.php adding tests for YOURLS functionality 2022-10-23 13:09:54 +02:00

Running all unit tests

Since it is non-trivial to setup all dependencies for our unit testing suite, we provide a docker image that bundles all of them into one container, both phpunit for PHP and mocha for JS.

You can fetch and run the image from the docker hub like this:

docker run --rm --read-only -v ~/PrivateBin:/srv:ro privatebin/unit-testing

The parameters in detail:

  • -v ~/PrivateBin:/srv:ro - Replace ~/PrivateBin with the location of the checked out PrivateBin repository on your machine. It is recommended to mount it read-only, which guarantees that your repository isn't damaged by an accidentally destructive test case in it.
  • --read-only - This image supports running in read-only mode. Only /tmp may be written into.
  • -rm - Remove the container after the run. This saves you doing a cleanup on your docker environment, if you run the image frequently.

You can also run just the php and javascript test suites instead of both:

docker run --rm --read-only -v ~/PrivateBin:/srv:ro privatebin/unit-testing phpunit
docker run --rm --read-only -v ~/PrivateBin:/srv:ro privatebin/unit-testing mocha

We also provide a Janitor image that includes the Cloud9 and Theia WebIDEs as well as the integrated unit testing utilities. See our docker wiki page for further details on this.

Running PHP unit tests

In order to run these tests, you will need to install the following packages and their dependencies:

  • phpunit
  • php-gd
  • php-sqlite3
  • php-xdebug (for code coverage reports)

Example for Debian and Ubuntu:

$ sudo apt install phpunit php-gd php-sqlite3 php-xdebug

To run the tests, change into the tst directory and run phpunit:

$ cd PrivateBin/tst
$ phpunit

Additionally there is the ConfigurationTestGenerator. Based on the configurations defined in its constructor, it generates the unit test file tst/ConfigurationCombinationsTest.php, containing all possible combinations of these configurations and tests for (most of the) valid combinations. Some of combinations can't be tested with this method, i.e. a valid option combined with an invalid one. Other very specific test cases (i.e. to trigger multiple errors) are covered in tst/PrivateBinTest.php. Here is how to generate the configuration test and run it:

$ cd PrivateBin/tst
$ php ConfigurationTestGenerator.php
$ phpunit ConfigurationCombinationsTest.php

Note that it can take an hour or longer to run the several thousand tests.

Running JavaScript unit tests

In order to run these tests, you will need to install the following packages and its dependencies:

  • npm

Then you can use the node package manager to install the latest stable release of mocha and nyc (for code coverage reports) globally and jsVerify, jsdom and jsdom-global locally:

$ npm install -g mocha nyc
$ cd PrivateBin/js
$ npm install

Example for Debian and Ubuntu, including steps to allow the current user to install node modules globally:

$ sudo apt install npm
$ sudo mkdir /usr/local/lib/node_modules
$ sudo chown -R $(whoami) $(npm config get prefix)/{lib/node_modules,bin,share}
$ ln -s /usr/bin/nodejs /usr/local/bin/node
$ npm install -g mocha nyc
$ cd PrivateBin/js
$ npm install

To run the tests, just change into the js directory and run nyc (will produce coverage report) or just mocha:

$ cd PrivateBin/js
$ nyc mocha

Property based unit testing

In the JavaScript unit tests we use the JSVerify library to leverage property based unit testing. Instead of artificially creating specific test cases to cover all relevant paths of the tested code (with the generated coverage reports providing means to check the tested paths), property based testing allows us to describe the patterns of data that are valid input.

With each run of the tests, for each jsc.property 100 random inputs are generated and tested. For example we tell the test to generate random strings, which will include empty strings, numeric strings, long strings, unicode sequences, etc. This is great for finding corner cases that one might not think of when explicitly writing one test case at a time.

There is another benefit, too: When an error is found, JSVerify will try to find the smallest, still failing test case for you and print this out including the associated random number generator (RNG) state, so you can reproduce it easily:

[...]

  30 passing (3s)
  1 failing

  1) Helper getCookie returns the requested cookie:
     Error: Failed after 30 tests and 11 shrinks. rngState: 88caf85079d32e416b; Counterexample: ["{", "9", "9", "YD8%fT"]; [" ", "_|K:"]; 

[...]

Of course it may just be that you need to adjust a test case if the random pattern generated is ambiguous. In the above example the cookie string would contain two identical keys "9", something that may not be valid, but that our code could encounter and needs to be able to handle.

After you adjusted the code of the library or the test you can rerun the test with the same RNG state as follows:

$ nyc mocha test --jsverifyRngState 88caf85079d32e416b