How to Use the Profiler in a Functional Test

It's highly recommended that a functional test only tests the Response. But if you write functional tests that monitor your production servers, you might want to write tests on the profiling data as it gives you a great way to check various things and enforce some metrics.

機能テストではレスポンスのみをテストすることを強くお勧めします。ただし、運用サーバーを監視する機能テストを作成する場合は、プロファイリング データでテストを作成することをお勧めします。これにより、さまざまなことをチェックし、いくつかのメトリックを適用するための優れた方法が得られるからです。

Enabling the Profiler in Tests

Collecting data with the Symfony Profiler can slow down your tests significantly. That's why Symfony disables it by default:

Symfony プロファイラーでデータを収集すると、テストが大幅に遅くなる可能性があります。そのため、Symfony はデフォルトで無効にしています:
  • YAML
    YAML
  • XML
    XML
  • PHP
    PHP
1
2
3
4
5
 
# config/packages/test/web_profiler.yaml

# ...
framework:
    profiler: { enabled: true, collect: false }

Setting collect to true enables the profiler for all tests. However, if you need the profiler only in a few tests, you can keep it disabled globally and enable the profiler individually on each test by calling $client->enableProfiler().

collect を true に設定すると、すべてのテストでプロファイラーが有効になります。ただし、いくつかのテストでのみプロファイラーが必要な場合は、グローバルに無効にし、$client->enableProfiler() を呼び出して各テストでプロファイラーを個別に有効にすることができます。

Testing the Profiler Information

The data collected by the Symfony Profiler can be used to check the number of database calls, the time spent in the framework, etc. All this information is provided by the collectors obtained through the $client->getProfile() call:

Symfony プロファイラーによって収集されたデータは、データベース呼び出しの数、フレームワークで費やされた時間などを確認するために使用できます。このすべての情報は、$client->getProfile() 呼び出しを通じて取得されたコレクターによって提供されます。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
 
// tests/Controller/LuckyControllerTest.php
namespace App\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class LuckyControllerTest extends WebTestCase
{
    public function testRandomNumber()
    {
        $client = static::createClient();

        // enable the profiler only for the next request (if you make
        // new requests, you must call this method again)
        // (it does nothing if the profiler is not available)
        $client->enableProfiler();

        $crawler = $client->request('GET', '/lucky/number');

        // ... write some assertions about the Response

        // check that the profiler is enabled
        if ($profile = $client->getProfile()) {
            // check the number of requests
            $this->assertLessThan(
                10,
                $profile->getCollector('db')->getQueryCount()
            );

            // check the time spent in the framework
            $this->assertLessThan(
                500,
                $profile->getCollector('time')->getDuration()
            );
        }
    }
}

If a test fails because of profiling data (too many DB queries for instance), you might want to use the Web Profiler to analyze the request after the tests finish. It can be achieved by embedding the token in the error message:

プロファイリング データが原因でテストが失敗した場合 (DB クエリが多すぎるなど)、テスト終了後に Web プロファイラーを使用してリクエストを分析することをお勧めします。これは、エラー メッセージにトークンを埋め込むことで実現できます。
1
2
3
4
5
6
7
8
 
$this->assertLessThan(
    30,
    $profile->getCollector('db')->getQueryCount(),
    sprintf(
        'Checks that query count is less than 30 (token %s)',
        $profile->getToken()
    )
);

Note

ノート

The profiler information is available even if you insulate the client or if you use an HTTP layer for your tests.

プロファイラー情報は、テストに HTTP レイヤーを使用する場合、クライアントを分離した場合でも利用できます。

Tip

ヒント

Read the API for built-in data collectors to learn more about their interfaces.

組み込みデータ コレクターの API を読んで、そのインターフェイスの詳細を確認してください。