Blackfire Player v1.0

What is the Blackfire Player?

It is a powerful Web Crawling, Web Testing, and Web Scraper application. It provides a nice DSL to crawl HTTP services, assert responses, and extract data from HTML/XML/JSON responses.

The Player is built to let developers execute any HTTP-based scenario, such as simulating a user journey through an app, or executing various scripts. It enables to assert on scenario results, including HTTP responses and Blackfire assertions.

Although we built it especially to enable Blackfire users to execute performance tests automatically, it can be used independently from Blackfire… Which makes it an even more interesting solution, if you’re willing to develop or simplify a test suite!

Version 1.0 of the Blackfire Player comes with a bunch of improvements.

Oh, and the Player is Open Source!

Using the Blackfire Player DSL within the .blackfire.yml file

Until the Player v1.0, there was two different ways to execute scenarios and check performance assertions with Blackfire.

1. Use the .blackfire.yml file to define tests and scenarios. Those scenarios where HTTP requests which would be profiled independently from each other. That would cover basic use cases, and was the go-to solution for most of our users.
2. Use the .blackfire.yml file to define tests and the Player to define scenarios. The Player DSL would enable to write more complex and robust scenarios, such as test a whole conversion funnel.

Now, the .blackfire.yml file support the Player DSL: you get the best of the two worlds! Head over to the documentation and find out how you can expand your scenario capacities.

Specific perk: this enables to profile automatically pages which are located behind an OAuth or a login form.

Bonus perk: you can use environment variables, for instance if your production environment is different from your staging environment.

One build for multiple scenarios

Until recently, each scenario described in a .bkf file would create a new build in Blackfire. If you had multiple scenarios belonging together, it was making things difficult to have an overview of the execution results.

A side win of this is that build report notifications now become more accurate. As a single .bkf file was able to kick-off several builds, you would receive as many build report notifications, causing a lot of noise on your communication channels (who likes a Slack channel with useless messages?). Now you’ll be able to focus!

Happy performance testing!