From 8cdb34180a3e13f7b9548b38afe2d23b4908c60e Mon Sep 17 00:00:00 2001 From: Sean Madsen <sean@seanmadsen.com> Date: Sat, 1 Jul 2017 19:56:04 -0600 Subject: [PATCH] Minor formatting changes --- docs/testing/phpunit.md | 39 ++++++++++++++++---------------- docs/testing/selinium.md | 48 ++++++++++++++++++++-------------------- docs/testing/setup.md | 10 +++------ docs/testing/upgrades.md | 17 +++++--------- 4 files changed, 52 insertions(+), 62 deletions(-) diff --git a/docs/testing/phpunit.md b/docs/testing/phpunit.md index 71d8fc43..3519e162 100644 --- a/docs/testing/phpunit.md +++ b/docs/testing/phpunit.md @@ -1,21 +1,21 @@ -PHP tests ensure that CiviCRM's PHP logic is working as expected -- for example, -ensuring that the 'Contact.create' API actually creates a contact. +PHP tests ensure that CiviCRM's PHP logic is working as expected — for example, +ensuring that the 'Contact.create' API actually creates a contact. -These tests are written with PHPUnit. The PHP tests are grouped into suites -(api_v3_AllTests, CRM_AllTests, and Civi\AllTests). +These tests are written with PHPUnit. The PHP tests are grouped into suites +(`api_v3_AllTests`, `CRM_AllTests`, and `Civi\AllTests`). ## Setup These tests required the latest supported version of PHPUnit. This is included -with [buildkit]. +with [buildkit](/tools/buildkit.md). It is possible that using the wrong configuration for tests will cause your main -local database to be used for testing, and will leave it unusable afterwards. +local database to be used for testing, and will leave it unusable afterwards. -To make sure this doesn't happen set up your local environment to point to the -test database before running your tests. +To make sure this doesn't happen set up your local environment to point to the +test database before running your tests. -Create a civicrm.settings.test.php in the same directory as your +Create a civicrm.settings.test.php in the same directory as your `civicrm.settings.php` using this template: ```php @@ -29,13 +29,13 @@ Finally tell CiviCRM where to find your settings file. export CIVICRM_SETTINGS="/path/to/civicrm.settings.test.php" ``` -If you want to run unit tests (and not WebTests or E2E tests) set the +If you want to run unit tests (and not WebTests or E2E tests) set the environment variable `CIVICRM_UF` to "UnitTests". This can also be set using the `env` command to change the environment just for a single command. !!! warning - Beware that if your tests change data in your CMS database - (creating system users etc.) your local build will be affected when running + Beware that if your tests change data in your CMS database + (creating system users etc.) your local build will be affected when running tests. ## Running Tests @@ -50,15 +50,15 @@ $ env CIVICRM_UF=UnitTests phpunit4 ./tests/phpunit/CRM/AllTests.php ## Writing Tests -When writing tests you should extend from `\CiviUnitTestCase`. +When writing tests you should extend from `\CiviUnitTestCase`. Test methods naming should follow the pattern: - Start with test - The name should describe what the test does, e.g. testCreateWithWrongParamsType -It is also recommended that your tests implement `HeadlessInterface` to run your -test against a fake, headless database. `CiviTestListener` will automatically +It is also recommended that your tests implement `HeadlessInterface` to run your +test against a fake, headless database. `CiviTestListener` will automatically boot Civi. These tests do not use a real CMS and are faster. Alternatively, if you wish to run a test in a live (CMS-enabled) environment, @@ -77,19 +77,18 @@ with that there are two methods: - `setUp` is executed before each test method - `tearDown` is executed after each test method -Sometimes it will be convenient to prepare test data for whole test case - +Sometimes it will be convenient to prepare test data for whole test case - in such case, you will want to put all the test data creation code in there. -Another option is for your test to implement `TransactionalInterface`. +Another option is for your test to implement `TransactionalInterface`. -That will guarantee that each test will be wrapped in a Transaction, that will +That will guarantee that each test will be wrapped in a Transaction, that will rollback automatically at the end of the test. !!! warning - Schema changes in your test will cause an auto-commit of all changes, and + Schema changes in your test will cause an auto-commit of all changes, and therefore the transaction will be ignored. If your tests create custom tables or change the database schema please be aware you may need to manually reset it. -[buildkit]: /tools/buildkit [civi-test-class]: https://github.com/civicrm/org.civicrm.testapalooza/blob/master/civi-test.md diff --git a/docs/testing/selinium.md b/docs/testing/selinium.md index 1618e5e3..2ca5bf4b 100644 --- a/docs/testing/selinium.md +++ b/docs/testing/selinium.md @@ -1,43 +1,43 @@ -Web tests ensure the overall system is working as expected – that is, ensuring -that the right things happen when you click on the right buttons. +Web tests ensure the overall system is working as expected – that is, ensuring +that the right things happen when you click on the right buttons. -Examples of web tests include that the event confirmation screen is displayed -when I hit the register for an event button, or that all 23 contacts are +Examples of web tests include that the event confirmation screen is displayed +when I hit the register for an event button, or that all 23 contacts are displayed when I search for contacts that live in France. -You can record tests using the Selenium IDE which you can download from the -Selenium website http://seleniumhq.org/. Web tests should be recorded using an -instance of CiviCRM that has standard sample data. +You can record tests using the Selenium IDE which you can download from the +[Selenium website](http://seleniumhq.org/). Web tests should be recorded using an +instance of CiviCRM that has standard sample data. -To ensure consistency, all tests should be carried out using the standard +To ensure consistency, all tests should be carried out using the standard CiviCRM sample data. ## Setup -[buildkit] should be installed. You will also need Java and Firefox. +[buildkit](/tools/buildkit.md) should be installed. You will also need Java and Firefox. ## Running the Web Tests 1. Open two terminals + 2. From Terminal 1: Launch the Selenium service -```bash -cd /path/to/civicrm -cd packages/SeleniumRC/ -bash selenium.sh -Runnning selenium-server-2.35.0 -Mar 06, 2015 8:58:22 PM org.openqa.grid.selenium.GridLauncher main -INFO: Launching a standalone server -``` + ```bash + $ cd /path/to/civicrm + $ cd packages/SeleniumRC/ + $ bash selenium.sh + Runnning selenium-server-2.35.0 + Mar 06, 2015 8:58:22 PM org.openqa.grid.selenium.GridLauncher main + INFO: Launching a standalone server + ``` + 3. From Terminal 2: Run the tests -```bash -cd /path/to/civicrm -cd tools -./scripts/phpunit WebTest_AllTests -``` + ```bash + $ cd /path/to/civicrm + $ cd tools + $ ./scripts/phpunit WebTest_AllTests + ``` ## See Also - [Selenium documentation](http://seleniumhq.org/docs/) - [Selenium reference](http://release.seleniumhq.org/selenium-core/1.0.1/reference.html) - -[buildkit]: /tools/buildkit diff --git a/docs/testing/setup.md b/docs/testing/setup.md index 84790969..1885e174 100644 --- a/docs/testing/setup.md +++ b/docs/testing/setup.md @@ -1,12 +1,8 @@ -The easiest way to get setup it to use buildkit. Buildkit will install the tools -necessary for running the tests and creating local CiviCRM sites. - -You can download [CiviCRM buildkit](/tools/buildkit) which includes all the test tools. -From there you can create a test site using [civibuild](/tools/civibuild). +The easiest way to get set up to run the automated tests is to use [buildkit](/tools/buildkit.md) which will install the tools necessary for running the tests and creating local CiviCRM sites with [civibuild](/tools/civibuild.md). !!! info - When writing new tests or making any changes make sure you run [civilint](/tools/civilint) + When writing new tests or making any changes make sure you run [civilint](/tools/civilint.md) to ensure your changes match our coding style. !!! tip - If you are using PhpStorm, you can [run the tests from within PhpStorm](/tools/phpstorm/#testing) (which is especially helpful because you can set breakpoints and inspect variables while the tests run). \ No newline at end of file + If you are using PhpStorm, you can [run the tests from within PhpStorm](/tools/phpstorm.md#testing) (which is especially helpful because you can set breakpoints and inspect variables while the tests run). \ No newline at end of file diff --git a/docs/testing/upgrades.md b/docs/testing/upgrades.md index 23d3af50..9df2df74 100644 --- a/docs/testing/upgrades.md +++ b/docs/testing/upgrades.md @@ -1,15 +1,10 @@ -Upgrade tests provide a basic sanity check on the DB upgrade logic – -they ensure that the upgrade process does not cause a crash when upgrading -from an older version. +Upgrade tests provide a basic sanity check on the DB upgrade logic – +they ensure that the upgrade process does not cause a crash when upgrading +from an older version. -They are suitable for checking issues in the DB upgrade logic – -but do not check for issues in the administrative experience or in the +They are suitable for checking issues in the DB upgrade logic – +but do not check for issues in the administrative experience or in the CMS-integration. -Upgrade tests are run daily on the Jenkins [continuous integration][ci] server. +Upgrade tests are run daily on the Jenkins [continuous integration](/testing/continuous-integration.md) server. -If you are working on a core upgrade you can save some time and check out this -handy [test-helper] to run upgraders from specific versions. - -[ci]: /testing/continuous-integration -[test-helper]: https://github.com/civicrm/civicrm-buildkit/blob/master/doc/daily-coding.md#upgrade-tests -- GitLab