Automatically Profiling Ajax Requests

The Blackfire Player is a very powerful tool to execute HTTP-based testing scenarios. It is Open-Source, and can be used to automate Blackfire profiling just as well as to execute any other type of scenario within your testing pipeline.

Scripting Ajax Requests with the Player

A common use case in a Web application: Ajax requests. Let’s have a look at how the Player can support profiling them automatically, and what we do within our own test suite.

When you, as a user, navigate to your Blackfire Dashboard, there are two requests that are executed in Ajax: one to get a security token, and one in order to load all of your profiles.

As those are business critical requests for Blackfire (that’s the most important content to display to our users, and it’s the landing page when you login to Blackfire!), it’s important for us to profile them regularly and make sure their performance meet our expectations (read more about writing performance assertions in our doc).

Here’s how we do it:

scenarios: |
    #!blackfire-player

    name "BKF Scenarios"

    scenario
        name 'Load Profiles List'

        click link('Dashboard')
            name 'Dashboard page'
            expect current_url() == endpoint ~ '/dashboard'
            expect status_code() == 200

        visit url('/jwt') // this is an Ajax request
            name 'JWT'
            method 'POST'
            set jwt_token json('token')
            expect status_code() == 200

        visit url('/web-api/my-profiles')  // this is an Ajax request
            name 'Web-Api My profiles'
            header 'Authorization: Bearer ' ~ jwt_token
            expect status_code() == 200
            expect json('_links.current.href') == '/web-api/profiles?page=1'

Let’s have a look at some tricks in this scenario:

Writing Expectations

Expectations are expressions evaluated against the current HTTP response. If one of them returns a falsy value, Blackfire Player stops the run and generates an error.

In our scenario, it is rather useful as there’s no need to even consider testing our Ajax requests, or anything else, if we don’t get a 200 when loading `/dashboard`.

Using and storing a temporary variable

Variables and options can be defined for an entire scenario. In our use case, the token is generated for a one-off usage. It has a limited life span, but in our use case, can be used for multiple queries.

By setting it at the `visit url(‘/jwt’)` step as a `json()` element, the value will be kept throughout the entire scenario. So we could even use it for further requests than `visit url(‘/web-api/my-profiles’)` and its `Authorization: Bearer` header.

We hope you’ll find this useful!

Don’t forget that the Player is Open Source! Your contributions are welcome for the whole community!

Happy profiling,