- The Platform Configurator
- Getting Started with Selenium for Automated Website Testing
- Getting Started with Appium for Mobile Native Application Testing
- Selenium Bootcamp by Dave Haeffner
- Appium Bootcamp by Dave Haeffner and Matthew Edwards
With Sauce Labs you can run automated tests of your web apps against a wide variety of device/operating system/browser combinations. This topic provides you with the information and code examples you need to get your PHP tests up and running with Sauce.
Example Only The code in this topic is presented as an example only, since your tests and testing environments may require specialized scripting. This information should be taken only as an illustration of how you could set up your tests with Sauce Labs, and is not directly supported by Sauce.
The code in this topic is presented as an example only, since your tests and testing environments may require specialized scripting. This information should be taken only as an illustration of how you could set up your tests with Sauce Labs, and is not directly supported by Sauce.
You need to have these components installed to set up testing on Sauce with PHP:
- You must have PHP set up on your system before you start testing.
Mac OS X comes with PHP installed, as long as you're running version 5.3 or higher, you're ready to go! If you're a Windows user, you can find instructions for setting up PHP on Windows at PHP.net.
- Windows users must also enable the PHP curl library and OpenSSL support to get the best performance from your PHP setup.
For more information, see Installing Extensions for Windows on the php.net website as well as these setup topics:
- If you want to set up your tests to use a PHP framework, you can check out our repository of testing framework examples in our GitHub repo.
You can set up any PHP test you've already written to run on Sauce, regardless of the testing framework it uses. All you need to do is change the test from running locally, to running on the Sauce cloud by defining the sauce URL, your authentication credentials, and a set of desired capabilities for the test.
This example shows how you could edit the existing test to run on Sauce. You can use the Platform Configurator to specify the desired capabilities for any browser/platform combination you want.
You can also clone this script directly from our GitHub repo.
Running Local Tests
Running Tests in Parallel
You can run your tests in parallel at two levels, and you can run your tests in parallel across multiple browsers. For example, if you have 10 tests and want to run on five browsers, this would be parallelism of five. You can also run tests across browsers and each test in parallel. Using our previous example this would be more like 50 parallel tests. Doing this requires that your tests are written in a way that they do not collide with one another, as described in our Best Practice topics avoiding external test dependencies and avoiding dependencies between tests.
Match Thread Count to Concurrency Limit
You should match your thread count to your concurrency limit, which is shown in the My Account section of your user profile information on the Sauce Labs dashboard.
For more information, check out the example scripts in our GitHub repo.
Reporting Test Results
By default, Sauce Labs doesn't know how to display the name of your test. Sausage comes up with a good name (
TestClass::testFunction) and reports it with your test so it's easy to find on your dashboard. Similarly, Sauce has no way to know if a particular test passed or failed. Sausage catches any failed assertions and reports the status of the test to Sauce after it's complete. Upon test failure Sausage will generate an authorized link to the failed job report on the Sauce Labs website, to facilitate reporting to people who need to know the details of the test. The job remains private (unless you change the status yourself), but others can follow the link without needing to log in with your credentials. See the topic Building Links to Test Results for more information.
You should also follow our recommended best practice of adding build numbers, tags, and other identifying information to your tests so you can easily find and manage them in your test results and archives pages, and associate tests with build numbers in your continuous integration pipeline.