Testing

PHPUnit + WebTestCase = your Vitest + Playwright-lite for the server. You don't need a hundred tests on day one - a few route/auth smoke tests already pay rent.

Run tests

php bin/phpunit
# or
vendor/bin/phpunit

Maker can scaffold:

php bin/console make:test

Functional / browser kit style

<?php

namespace App\Tests\Controller;

use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;

class PostControllerTest extends WebTestCase
{
    public function testIndexLoads(): void
    {
        $client = static::createClient();
        $client->request('GET', '/posts');

        $this->assertResponseIsSuccessful();
        $this->assertSelectorTextContains('h1', 'Posts');
    }
}

Comments for the code above:

• createClient() boots the kernel and lets you click through like a tiny browser
• Assertions on status + selectors catch Twig regressions
• Database: use DAMADoctrineTestBundle or reset schema in setUp when tests write data - follow your project's existing pattern

Auth in tests

<?php

$user = /* fetch or create a User fixture */;
$client->loginUser($user);
$client->request('GET', '/dashboard');
$this->assertResponseIsSuccessful();

Same idea as Laravel $this->actingAs($user).

Unit vs integration

Style	Good for
Pure unit (no kernel)	services with injected deps + doubles
KernelTestCase	container / Doctrine integration
WebTestCase	HTTP + Twig + security smoke

Don't mock the universe. Test the behavior you care about - especially auth boundaries.

FE parallel

If your brain is Jest/Vitest: assertions feel familiar. The weird part is booting a kernel instead of importing a React tree - once you've done it twice, it's fine.

Next: Messenger - queues without the full Rabbit deep dive.

Best,

-- ł.