Skip to content

Latest commit

 

History

History
42 lines (27 loc) · 2.79 KB

HACKING.md

File metadata and controls

42 lines (27 loc) · 2.79 KB

Code Style

All code submitted to phpsql must comply with the PSR-2 standard to be accepted. You can use php-codesniffer to test if that is the case. Furthermore you are advised to orientate your coding-style for phpsql on the already existing phpsql-code.

Branches / Issues

For any change on phpsql, there should be an issue on github. Branches related to issues should be named like 'issue#1234', where 1234 is the number of that issue.

Tests

There are several ways to test your changes. Before pushing any code-changes to phpsql, you should at least make sure they do not fail the automated tests.

Automated tests / PHPUnit

Before pushing any code-change to phpsql, you must execute the automated tests using phpunit. Simply executing phpunit without any parameters should execute all automated tests in a few seconds (depending on your machine). You are advised to execute the automated tests before you begin coding to get a feel on how well they execute on your machine. If they take a substancial longer time to execute on the patched version, you should investigate if your changes cause any slowdowns.

Only patches that pass all automated tests will be accepted!

There are three types of automated tests in phpsql: Behaviour-tests, Integration-tests and Unit-tests.

  • Behaviour-tests are tests which test the whole of phpsql as one big blackbox which can execute SQL statements. They tests end-user functions on an in-memory database by querying SQL-statements on an PDO-object. Example: Test if SELECT works by creating a table with CREATE-TABLE, INSERT a few data-sets and SELECT them to see if they match the inserted data.

  • Integration-tests are tests which test a bundle of related components together. Example: Set up a structure of Table-objects, ColumnData-objects and Indexes and see if they together correctly store and retrieve rows.

  • Unit-tests are tests which test one single component for correct behaviour. All depencies to other components are fulfilled by mocking these components. (Multiple classes together can be seen as one component if they directly depend on each other like BTree and BTreeNode.) Example: See if the DELETE-statement executor tries to delete the correct rows on the correct tables/indexes by mocking these components.

Benchmarking your changes

Before pushing any logical and/or big changes, you are advised to run the bin/benchmark.php script on the unchanged version and on the patched version to test if your patch cause any severe slowdowns.