Modern applications typically provide multiple options for authentication, almost always including options for logging in using common third party systems. Some apps even completely bypass native authentication and rely heavily on login from third party sources to grant access to their applications. In this scenario, thorough testing of that third party login system becomes vital to ensuring an easy and error free login experience for customers.
BlazeMeter includes sample Transactions for two common third-party login services:
These providers maintain public APIs that control login to a remote application using valid credentials for their service. During application testing, there are scenarios where you would want to avoid hitting the real service and perform thorough login testing using a Mock Service that simulates these public APIs. For example, you might want to mock the service when you are performance testing your application so that you can focus on the performance of the natively build services of your application.
The prebuilt Transaction bundles in BlazeMeter let you mock a service that controls access to your application through either Facebook or Salesforce login. The Transactions include the basic API requests, common positive and negative test scenarios, and common query parameters that you can customize based on the needs of your application.
Let's consider a sample scenario where your application leverages the Salesforce Login API for authentication. You need to create a Mock Service to test your application login, which will require hitting the Salesforce APIs.
- Click the Mock Service tab, and click Asset Catalog.
- In the Filter by Service drop-down list, select Salesforce Login Sample:
- Examine the available Transactions. Out of the box, BlazeMeter includes the following:
- Successful requests to the Salesforce Authorization and Access Token APIs
- Unsuccessful requests to the Salesforce Authoriazation and Access Token APIs that fail for common reasons, including:
- Invalid Client ID
- Invalid Redirect URL
- Expired Authorization code
- Invalid client secret
- Find the 'Salesforce authorization token API with valid parameters' Transaction, and click the clone icon at the right of the Transaction row:
- Expand the newly created Transaction, which will have the same name appended by the phrase 'Cloned at <timestamp>'.
- Expand the Service drop-down list, and type the name of a new service to contain your duplicated transactions. For this example, we'll use My Salesforce Application for the service name:
- Click Add Service.
The new service is created.
- Click Save, and the cloned Transaction is moved to the My Salesforce Application service.
- Repeat Steps 4-5 to clone the positive Salesforce Access Token API Transaction, and any of the negative Transactions that you require. Instead of creating a new service, assign them to the My Salesforce Application service that you already created and click Save.
You should now have copies of all of the Salesforce Transactions that you need in your own service:
- Clean up the names for each Transaction.
Instead of a cloned timestamp, use the name and tags to distinguish your cloned Transactions from the template ones. For example, you could preface or append the Transaction name with your application name, or add a tag with your application name:
- Edit the Transaction request matching parameters as needed.
The Transactions were designed to require little to no customization. The query parameters for each required value are configured with regular expressions to match any value, meaning any input to the Transaction within a Mock Service will produce the desired result.
You can leave the Transactions as is with broad criteria, or you can update the parameter values to be more specific to your application, with its Client ID, Redirect URL, and other values. If you do that, exercise the live service so that you can copy in appropriate responses for your updated Transactions.
For this scenario, we did not edit the default request matching criteria or responses.
- Click the Mock Services page, and create a new template. Name the template Successful Salesforce Login, and drag the two positive Transactions into the template:
Both Transactions would be required for a successful login, because the Salesforce Login API requires both to pass through to the integrated application.
- Create a new template that collects all of the negative Salesforce login Transactions:
You now have templates for positive and negative scenarios that you can add to a Mock Service at any time to simulate successful or unsuccessful Salesforce logins to your application during your testing. In this example, any call to the APIs mocked by the Transactions will return the desired result, because of the broad matching criteria. This configuration is useful if you simply want to ensure the desired response for login during testing without consistently hitting the public API. The Transactions are fully customizable and can easily support more complex scenarios, as well.