DEV Community: SymfonyCasts

Playwright-PHP Changes the Game for Symfony Testing

Leanna Pelham — Tue, 29 Sep 2026 16:53:16 +0000

"We migrated our browser test suite from Panther to Playwright...

Went from ~39 seconds to ~18 seconds. And now it's possible to run this suite with paratest...since we can parallelize it now!"

Jon Wage

A test suite that relies on JavaScript, cut from ~39 seconds to ~18 seconds -
~50% faster?!

And now it can run in parallel with ParaTest?!

I've been working with Simon André on this new Playwright + Symfony setup, and the whole thing is kind of blowing my mind.

The architecture is incredibly clever and unlocks some things I didn't think were possible with end-to-end tests.

Let's start at the bottom.

Playwright

Playwright is a browser automation tool from
Microsoft.

It controls real Chromium, Firefox, and WebKit browsers, so your tests can click around, fill out forms, execute JavaScript and interact with your app like a real user.

The idea isn't new. We've had Selenium/WebDriver-style end-to-end testing for years.

The problem? It wasn't a great experience. It was slow, flaky, and generally painful to work with.

Playwright is a much more modern take on browser automation: fast, powerful, and built around today's web apps.

The official library is JavaScript/TypeScript.

But we're PHP developers. So...

Playwright-PHP

That's where playwright-php/playwright comes in.

Created by Simon along with other amazing contributors, its job - for our
purposes - is basically to get Playwright installed and usable for PHP
developers.

It gives us a PHP API for controlling Playwright and writing end-to-end tests from PHP.

Awesome!

Playwright + Symfony 🤯

But this is where things get really interesting.

Because Simon didn't stop at "Playwright, but for PHP".

With playwright-php/playwright-symfony, he asked:

What if we could make Playwright work with Symfony's kernel?

With traditional end-to-end testing - including tools like Symfony
Panther - the architecture looks like you'd expect:

Browser -> Web Server -> Symfony Kernel

The browser is a separate process, your app is behind a web server, and they talk over HTTP.

Totally normal.

But Playwright has a powerful trick up its sleeve: it can intercept network requests and provide the response itself.

And playwright-symfony takes that idea somewhere I absolutely did not expect.

From Browser Request to Symfony Request

When the browser requests a page from your app, the request is intercepted
before it ever reaches a web server.

It's converted into a Symfony Request, passed directly to the Symfony kernel running inside your test, and the resulting Symfony Response is handed straight back to the browser.

So this:

Browser -> Web Server -> Symfony Kernel

becomes this:

Browser -> Symfony Kernel

THE WEB SERVER IS A LIE!!!

🤯🤯🤯

And this isn't a fake browser or some DOM simulation.

It's still a real Chromium, Firefox or WebKit browser.

It's rendering the page.

It's executing the JavaScript.

Fetch requests, Turbo, Stimulus, whatever your frontend is doing - it's
happening in a real browser.

But the Symfony requests are being handled in-process by your kernel.

That combination is incredible:

Real browser + real JavaScript + in-process Symfony kernel.

And suddenly the boundary that normally separates an E2E test from your Symfony test environment basically disappears. Your test and your application share the same process, so:

The container is right there.

The profiler is right there.

Your mocked services are right there.

This feels less like "another browser testing tool" and more like a new kind of Symfony test: the browser realism of an end-to-end test with the superpowers we normally only get from kernel testing.

That is just so cool.

Zenstruck Browser

And... this is where I got involved.

Once I understood what was happening here, it felt game changing for Symfony end-to-end testing. I wanted to push it further and get it into the hands of more people.

So I brought Playwright support to zenstruck/browser.

Zenstruck Browser is an expressive testing layer for Symfony apps. It gives you a fluent API for clicking links, filling forms, making assertions,
authenticating users, accessing the container, working with the profiler and a bunch more.

For years, when you needed a browser that actually runs your JavaScript, we supported Symfony Panther.

Panther has been awesome for us. It brought end-to-end testing into the Symfony ecosystem and made something that was traditionally pretty painful much easier to use.

But with all this new Playwright + Symfony magic available, I made a pretty big change:

I added Playwright support... and deprecated Panther.

And the really exciting part isn't just that Zenstruck Browser can now drive Playwright. It's how much of the experience from our normal kernel tests we can bring along with it.

Want to authenticate a user without visiting the login page?

$this->playwrightBrowser()
    ->actingAs($user)
    ->visit('/account')
;

That logs the user in directly through Symfony's session, while the real browser gets the resulting authentication cookie.

Want to test redirects? You can stop on them, assert exactly where they're
going, then follow them:

$this->playwrightBrowser()
    ->interceptRedirects()
    ->visit('/account')
    ->assertRedirectedTo('/login')
;

And exceptions are especially cool.

Normally, once a real browser and web server are involved, an exception happens on the other side of that boundary. But because Playwright's requests are running directly through our kernel, Zenstruck Browser can actually catch the real PHP exception:

$this->playwrightBrowser()
    ->expectException(\DomainException::class)
    ->visit('/boom')
;

Not "the page returned a 500".

The actual exception!

DomainException: You cannot purchase this product.

We also get container access, profiler support, shared assertions, cookie
handling and a bunch of the other conveniences that make kernel tests so nice to work with.

So instead of choosing between:

"nice Symfony functional test" and "real browser with JavaScript"

...we can get remarkably close to having both.

And that's what made me want to push this forward.

Wait... DAMA Works?!

My favorite part? What this means for your database.

If you write Doctrine tests, you might use DAMADoctrineTestBundle. It wraps each test in a transaction and rolls it back when the test finishes. Your database is clean again instantly, and you never pay to rebuild it.

It's fantastic. But with end-to-end tests, it never worked.

It couldn't. Your test opens a transaction on its connection, but the browser talks to a web server in a different process, holding a different connection. That process can't see your uncommitted data. So the transaction trick was off the table and you were back to purging tables or reloading fixtures between every single test.

But now the request is handled inside your test process, on the same
connection.

So DAMA just... works.

// persisted in your test - never committed
ProductFactory::createOne(['name' => 'Widget']);

$this->playwrightBrowser()
    ->visit('/products')
    ->assertSeeIn('#products', 'Widget') // the browser sees it!
;

The real browser renders that product. Your JavaScript can fetch it. And when the test ends, it all disappears - nothing ever hits the database.

It works in the other direction too: if the request writes something, your test sees it afterwards, and it's still rolled back at the end.

So we've dropped the web server, and now we've dropped the
rebuild-the-database-every-test tax with it. And we haven't even parallelized anything yet.

And... ParaTest

Remember the other part of Jon's quote?

"And now it's possible to run this suite with paratest... since we can parallelize it now!"

Because the Symfony app is running inside the test process instead of behind a shared web server, these Playwright tests can play nicely with
ParaTest.

So now we're not just talking about fast Playwright tests.

We're talking about a Playwright suite you can actually run in parallel - without giving up any of the above.

That's how a Playwright suite goes from something you're nervous to grow into something you can actually keep adding to.

This Changes the Equation

Browser tests have always come with trade-offs. You want a browser that actually runs your JavaScript? Great. But now you're dealing with a web server, separate processes, slower tests and less access to Symfony itself.

This new Playwright + Symfony setup changes that equation. For the most part, you stop choosing.

And, as Jon Wage showed us right at the beginning:

"...Went from ~39 seconds to ~18 seconds..."

That's not a small improvement.

I think Simon and the contributors to Playwright-PHP are building something
genuinely special here, and I'm incredibly proud to be part of it and excited to see where it goes next.

If you're testing Symfony apps in a browser, you should absolutely be paying attention to this project.

And we're building a full course on all of this:
Symfony End-to-End Testing: WebTestCase to Playwright

It's not out yet - head over there to read more and get notified the moment it's released.

Keeping Doctrine Entities Honest with DTOs and ObjectMapper

Leanna Pelham — Thu, 25 Jun 2026 18:27:13 +0000

Originally posted on https://symfonycasts.com/blog/honest-entities

Your Doctrine entities are lying to you!

For years, the standard way to build Doctrine entities in Symfony has looked
something like this (and it's still what MakerBundle generates today):

#[ORM\Entity]
class ConferenceTalk
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[Assert\NotBlank]
    #[ORM\Column(length: 255)]
    private ?string $title = null;

    #[ORM\Column(type: Types::TEXT, nullable: true)]
    private ?string $abstract = null;

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getTitle(): ?string
    {
        return $this->title;
    }

    public function setTitle(?string $title): static
    {
        $this->title = $title;

        return $this;
    }

    public function getAbstract(): ?string
    {
        return $this->abstract;
    }

    public function setAbstract(?string $abstract): static
    {
        $this->abstract = $abstract;

        return $this;
    }
}

At first glance, this looks perfectly reasonable.

The title field is required. We know that because it has a
NotBlank constraint and the database column is not nullable.

But look closer.

private ?string $title = null;

public function setTitle(?string $title): static

public function getTitle(): ?string

According to the PHP type system, the title is optional. In fact, the public
API of this class explicitly allows us to set it to null.

That means this is perfectly valid:

$talk = new ConferenceTalk();

And so is this:

$talk = new ConferenceTalk();
$talk->setTitle(null);

Both objects represent a conference talk that can never be successfully
persisted.

Eventually, Doctrine catches the problem:

$talk = new ConferenceTalk();

$entityManager->persist($talk);
$entityManager->flush(); // boom!

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'title' cannot be null

The database knows that a conference talk must have a title.

Our PHP code does not.

So why do we build entities this way?

Historically, this pattern was optimized for simplicity.

A single object could be used everywhere:

Render a form
Receive submitted data
Validate that data
Persist it to the database

For beginners, this is fantastic. There is very little ceremony, very little
boilerplate, and very little to learn before you can build working CRUD
screens.

The tradeoff is that entities end up serving two very different purposes.

They represent persisted application data, but they also act as form models.
Because user input is often incomplete or invalid, entities need to be able
to temporarily hold data that should never actually exist in the database.

That's why we end up with a seemingly contradictory combination:

#[Assert\NotBlank]
#[ORM\Column(nullable: false)]
private ?string $title = null;

The validator says the field is required.

The database mapping says it's required.

The PHP type says it's optional.

Those statements don't all agree.

But what if our entities didn't need to act as form models at all?

What if incomplete user input lived somewhere else?

Giving Incomplete Data Somewhere Else to Live

Validation is not the problem.

The problem is that we're asking our entity to be two different things at the
same time:

A valid ConferenceTalk entity
A form data model (a temporary container for incomplete user input)

So let's split those responsibilities.

First, create a DTO (Data Transfer Object) that represents the form data:

final class ConferenceTalkDto
{
    #[Assert\NotBlank]
    public ?string $title = null;

    public ?string $abstract = null;
}

Unlike our entity, the DTO is allowed to be incomplete.

That's its job. It represents data coming from the outside world before we've
proven that it's valid.

Our entity can finally express its real requirements:

#[ORM\Entity]
class ConferenceTalk
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    private string $title;

    #[ORM\Column(type: Types::TEXT, nullable: true)]
    private ?string $abstract = null;

    public function __construct(string $title)
    {
        $this->title = $title;
    }

    public function getTitle(): string
    {
        return $this->title;
    }

    public function getAbstract(): ?string
    {
        return $this->abstract;
    }

    public function setAbstract(?string $abstract): void
    {
        $this->abstract = $abstract;
    }
}

Notice what's changed.

The required title is no longer nullable and must be provided when the
entity is created:

public function __construct(string $title)
{
    $this->title = $title;
}

The optional abstract remains nullable, and does not have a constructor argument,
because it truly is optional.

Now the entity's API matches its actual requirements. If you want a
ConferenceTalk, you must provide a title: ""

$talk = new ConferenceTalk('Keeping Doctrine Entities Honest');

At this point, the PHP type system, the entity, and the database all agree on
what is required and what is optional.

We've eliminated an entire category of impossible states.

A ConferenceTalk can no longer exist without a title.

The natural objection is:

Great, but now I have two classes. Do I need to manually map data between them?

Historically, yes - and that was a legitimate objection.

And that boilerplate is one of the reasons many Symfony applications have
continued using entities directly with forms and validation.

This is where Symfony's ObjectMapper component
(added in 7.3) changes the tradeoff.

Instead of manually creating entities from DTOs:

$talk = new ConferenceTalk($dto->title);

$talk->setAbstract($dto->abstract);

we can let ObjectMapper do the transformation for us:

$talk = $objectMapper->map($dto, ConferenceTalk::class);

One nice detail is that this remains fully type-safe. Thanks to generics,
IDE autocompletion and static analysis tools can correctly infer that
$talk is a ConferenceTalk instance.

The DTO remains flexible enough to receive and validate user input. The
entity remains strict enough to represent valid application data.
ObjectMapper bridges the gap between the two.

In other words:

The DTO receives and validates user input
The entity represents valid application data
ObjectMapper moves data between them

Each object has a single responsibility, and each object tells the truth
about what it represents.

What Does This Look Like in Practice?

The nice thing about this approach is that it doesn't require a massive
rewrite. Starting from a standard make:crud setup, only five things change:

Add a DTO
Update the form to map to the DTO instead of the entity
Make the entity requirements honest
Update the create controller
Update the edit controller

1. Add a DTO

First, I created a new ConferenceTalkDto class:

// src/Dto/ConferenceTalkDto.php

final class ConferenceTalkDto
{
    #[Assert\NotBlank]
    public ?string $title = null;

    public ?string $abstract = null;
}

This class is now responsible for receiving user input and holding invalid
data during validation.

2. Update the Form

The form barely changes.

Before:

// src/Form/ConferenceTalkType.php

public function configureOptions(OptionsResolver $resolver): void
{
    $resolver->setDefaults([
        'data_class' => ConferenceTalk::class,
    ]);
}

After:

// src/Form/ConferenceTalkType.php

public function configureOptions(OptionsResolver $resolver): void
{
    $resolver->setDefaults([
        'data_class' => ConferenceTalkDto::class,
    ]);
}

That's it.

The form now hydrates the DTO instead of the entity.

3. Make the Entity Honest

With validation moved to the DTO, the entity can finally express what is
actually required.

Before:

// src/Entity/ConferenceTalk.php

#[Assert\NotBlank]
#[ORM\Column(length: 255)]
private ?string $title = null;

// ...
public function setTitle(?string $title): void // (nullable property)
{
    $this->title = $title;
}

public function getTitle(): ?string // (nullable return type)
{
    return $this->title;
}

After:

// src/Entity/ConferenceTalk.php

#[ORM\Column(length: 255)]
private string $title;

public function __construct(string $title)
{
    $this->title = $title;
}

// ...
public function setTitle(string $title): void // (non-nullable property)
{
    $this->title = $title;
}

public function getTitle(): string // (non-nullable return type)
{
    return $this->title;
}

The title is no longer nullable because a conference talk without a title
should never exist.

4. Update the Create Controller

This is where ObjectMapper comes in.

Before, the form populated the entity directly:

// src/Controller/ConferenceTalkController.php

$talk = new ConferenceTalk();

$form = $this->createForm(
    ConferenceTalkType::class,
    $talk,
);

$form->handleRequest($request);

if ($form->isSubmitted() && $form->isValid()) {
    $entityManager->persist($talk);
    $entityManager->flush();

    // ...
}

// ...

Now the form populates the DTO:

// src/Controller/ConferenceTalkController.php

$dto = new ConferenceTalkDto();

$form = $this->createForm(
    ConferenceTalkType::class,
    $dto,
);

$form->handleRequest($request);

if ($form->isSubmitted() && $form->isValid()) {
    $talk = $objectMapper->map(
        $dto,
        ConferenceTalk::class,
    );

    $entityManager->persist($talk);
    $entityManager->flush();

    // ...
}

// ...

5. Update the Edit Controller

Editing existing entities works too.

Before:

// src/Controller/ConferenceTalkController.php

$form = $this->createForm(
    ConferenceTalkType::class,
    $talk,
);

$form->handleRequest($request);

if ($form->isSubmitted() && $form->isValid()) {
    $entityManager->flush();

    // ...
}

// ...

After:

// src/Controller/ConferenceTalkController.php

$dto = $objectMapper->map(
    $talk,
    ConferenceTalkDto::class,
);

$form = $this->createForm(
    ConferenceTalkType::class,
    $dto,
);

$form->handleRequest($request);

if ($form->isSubmitted() && $form->isValid()) {
    $objectMapper->map(
        $dto,
        $talk,
    );

    $entityManager->flush();

    // ...
}

// ...

Notice what's happening.

For creation, ObjectMapper creates a new entity from the DTO.

For editing, ObjectMapper first creates a DTO from the entity so the form
has something to edit. Once validation succeeds, it maps the DTO back onto
the existing entity.

The pattern remains consistent:

Forms work with DTOs
Validation runs on DTOs
Entities remain valid application data

Most importantly, we no longer have a period of time when a ConferenceTalk exists without a title!

Want to see all of these changes together?
Check out the full diff to see this pattern applied to a real Symfony application.

ObjectMapper Changes the Equation

For years, we've accepted a contradiction.

The validator says required.

The database says required.

The entity says optional.

We allow entities to exist in invalid states because they also need to act as form models. We make required properties nullable. We rely on validation to enforce requirements that our type system cannot express.

The tradeoff made sense when entities doubled as form models.

But ObjectMapper changes the equation.

To be fair, this idea isn't entirely new.

Many Symfony developers have used DTOs for years, often with custom mapping
code or libraries such as symfonycasts/micro-mapper.

The challenge has never been whether DTOs are useful. The challenge has been standardization.

ObjectMapper brings this capability into Symfony itself, giving the ecosystem a first-class solution for moving data between DTOs and entities.

For the first time, this pattern feels practical enough to be considered a
mainstream Symfony approach rather than an advanced architectural choice.

That allows each object to focus on a single responsibility:

DTOs receive and validate user input
Entities represent valid application data

The result is a model where required data is actually required, optional data is actually optional, and entities can no longer be created in impossible states.

At least to me, that feels like a cleaner approach.

Should MakerBundle generate DTOs by default? Should make:crud offer a
DTO/ObjectMapper workflow? Have you already been using a pattern like this in your applications?

Maybe it's time for our entities to start telling the truth.

What do you think? Let us know in the comments!

Originally posted on https://symfonycasts.com/blog/honest-entities