Kapitola 17 · Praxe · Testování DDD kódu v Symfony

Testování DDD kódu v Symfony

Testování DDD kódu v Symfony: unit testy doménové vrstvy, InMemory repozitáře, integrační testy s Doctrine, funkční testy API, testy doménových událostí a architektonické testy.

Autor M. Katuščák

Doba čtení ≈ 31 min

Náročnost pokročilá

Publikováno · Aktualizováno 24. 4. 2025 · 29. 9. 2026

Obsah kapitoly

17.01 Filozofie testování v DDD#

Doménová vrstva v DDD nezávisí na frameworku ani na databázi, takže ji lze testovat přímo z PHPUnitu bez bootstrappingu Symfony kernelu. To je hlavní praktický rozdíl proti tradičním vrstveným architekturám, kde unit testy potřebují kontejner a každý z nich zaplatí bootstrap. Bez kernelu je jeden test řádově rychlejší a celou doménovou sadu se vyplatí spouštět po každé změně, ne jen v CI. Stavební kameny doménové vrstvy popisuje kapitola Základní koncepty DDD: entity, hodnotové objekty, agregáty a doménové události.

Testovací pyramida pro DDD

Testovací pyramida (koncept popularizovaný Mikem Cohnem v knize Succeeding with Agile, 2009 [1]) rozděluje testovací sadu do tří vrstev. Liší se rychlostí, mírou izolace a tím, kolik kódu jeden test pokryje:

§ Poznámka

Vrstvy testovací pyramidy

Unit testy – doménová vrstva (základ pyramidy, nejvíce testů) Testují izolované doménové objekty: value objects, entity, agregáty a doménové služby. Nepotřebují databázi ani framework. Jsou rychlé (stovky testů za sekundu). Cíl: ověřit doménová pravidla a invarianty.
Integrační testy – infrastrukturní vrstva (střed pyramidy) Testují spolupráci doménového kódu s infrastrukturou: Doctrine repozitáře, e-mailové odesílatele, messagingové systémy. Vyžadují databázi nebo jiné externí zdroje. Jsou pomalejší, ale ověřují mapování a persistenci. Cíl: ověřit, že infrastruktura správně implementuje doménová rozhraní.
Funkční testy – aplikační vrstva / API (špička pyramidy, nejméně testů) Testují celé use cases přes HTTP vrstvu nebo přímo přes aplikační služby. Simulují uživatele aplikace. Jsou nejpomalejší a nejkřehčí. Cíl: ověřit integraci všech vrstev v hlavních scénářích.

Poměr vrstev není konstanta

Pyramida říká, že pomalých testů má být méně než rychlých. V jakém poměru, neříká. Fowler k ní proto staví protipól ice-cream cone: sadu, ve které převažují pomalé testy přes UI. Rozpadá se ze tří důvodů: build trvá dlouho, drobná změna systému rozbije mnoho testů naráz a headless běh v pipeline je problematický [2]. Ham Vocke tvar pyramidy drží, na názvech Cohnových vrstev mu ale nezáleží. Trvá na dvou věcech: testy mají mít různou granularitu a čím výš v pyramidě, tím méně jich má být. Integrační testy pojímá úzce – každý ověřuje jediný integrační bod a zbytek nahradí test doubles [3].

Pro DDD projekt z toho plyne vodítko: těžiště sady kopíruje tloušťku doménové logiky. Bounded context s bohatým modelem unese širokou základnu unit testů. Kontext, který jen překládá HTTP požadavky na dotazy do databáze, takovou základnu nemá a jeho záruku nesou integrační testy. Kent C. Dodds na téže úvaze staví alternativu Testing Trophy s největší investicí do integrační vrstvy [4]. Formulovaná je pro JavaScript, ale otázka, kolik logiky se vlastně testuje v izolaci, platí i v PHP.

17.02 Unit testy doménové vrstvy#

Unit testy doménové vrstvy pokrývají největší podíl kódu a běží v řádu milisekund. Stačí jim PHPUnit a samotné doménové třídy; kernel, databázi ani fixtures nepotřebují.

Ukázky v této kapitole cílí na PHPUnit 13 a PHP 8.4. Na verzi tentokrát záleží víc než obvykle. PHPUnit 12 odstranil podporu metadat v doc-komentářích, takže @dataProvider, @covers, @test ani @group už nejsou pokyny pro framework – zůstávají obyčejným komentářem. Metadata se zapisují atributy z namespace PHPUnit\Framework\Attributes: #[DataProvider], #[TestWith], #[CoversClass], #[Group], #[Test] [5]. Test s @dataProvider přenesený z návodu pro PHPUnit 9 skončí chybou o chybějícím argumentu metody. Záludnější je @test: metoda bez prefixu test se tiše přestane spouštět.

Testování Value Objects

Test value objektu ověřuje tři věci: neplatný vstup vyhodí odpovídající výjimku, dvě instance se stejnou hodnotou jsou si rovny přes equals() a objekt zůstává neměnný – jiná hodnota znamená novou instanci.

◢ Vzor

Příklad: Test pro Email value object (PHPUnit)

php tests/UserManagement/Domain/ValueObject/EmailTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Domain\ValueObject;6 7use PHPUnit\Framework\Attributes\DataProvider;8use PHPUnit\Framework\TestCase;9use App\UserManagement\Domain\ValueObject\Email;10 11final class EmailTest extends TestCase12{13    public function testCreatesValidEmail(): void14    {15        $email = new Email('[email protected]');16 17        $this->assertSame('[email protected]', $email->value);18    }19 20    public function testNormalizesToLowercase(): void21    {22        // Normalizaci dělá pojmenovaná factory, ne konstruktor23        $email = Email::fromUserInput('[email protected]');24 25        $this->assertSame('[email protected]', $email->value);26    }27 28    #[DataProvider('invalidInputs')]29    public function testThrowsExceptionForInvalidInput(string $input): void30    {31        $this->expectException(\InvalidArgumentException::class);32 33        new Email($input);34    }35 36    /**37     * Data provider musí být od PHPUnit 11 statický a veřejný.38     *39     * @return iterable<string, array{string}>40     */41    public static function invalidInputs(): iterable42    {43        yield 'bez zavináče'    => ['not-an-email'];44        yield 'prázdný řetězec' => [''];45        yield 'chybí doména'    => ['jan@'];46        yield 'mezera uvnitř'   => ['jan [email protected]'];47    }48 49    public function testEqualityBySameValue(): void50    {51        $email1 = new Email('[email protected]');52        $email2 = new Email('[email protected]');53 54        $this->assertTrue($email1->equals($email2));55    }56 57    public function testInequalityForDifferentValues(): void58    {59        $email1 = new Email('[email protected]');60        $email2 = new Email('[email protected]');61 62        $this->assertFalse($email1->equals($email2));63    }64 65    public function testImmutabilityViaNewInstance(): void66    {67        $original = new Email('[email protected]');68        // Hodnotové objekty jsou neměnné – změna vyžaduje novou instanci69        $different = new Email('[email protected]');70 71        $this->assertSame('[email protected]', $original->value);72        $this->assertSame('[email protected]', $different->value);73        $this->assertFalse($original->equals($different));74    }75}

Pojmenované klíče v data provideru se objeví ve výstupu PHPUnitu, takže spadlý případ je vidět bez čtení testu: EmailTest::testThrowsExceptionForInvalidInput@chybí doména with data ('jan@'). Pro jeden nebo dva vstupy stačí atribut #[TestWith([''])] přímo nad metodou; samostatný provider se vyplatí od tří případů výš.

Testování entit

Test entity ověřuje, co entita dělá, ne jak vypadají její vlastnosti. Volá se veřejná metoda, ověřuje se výsledný stav přes další veřejné metody a u zakázaných operací se očekává konkrétní doménová výjimka. Přístup k privátním vlastnostem přes reflexi je signál, že test sleduje implementaci místo chování.

◢ Vzor

Příklad: Test pro User entitu

php tests/UserManagement/Domain/Model/UserTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Domain\Model;6 7use PHPUnit\Framework\TestCase;8use App\UserManagement\Domain\Event\UserRegistered;9use App\UserManagement\Domain\Model\User;10use App\UserManagement\Domain\ValueObject\UserId;11use App\UserManagement\Domain\ValueObject\Email;12use App\UserManagement\Domain\ValueObject\HashedPassword;13use App\UserManagement\Domain\ValueObject\UserName;14 15final class UserTest extends TestCase16{17    private UserId $userId;18    private Email $email;19 20    protected function setUp(): void21    {22        $this->userId = UserId::generate();23        $this->email  = new Email('[email protected]');24    }25 26    public function testRegistrationRecordsExactlyOneUserRegistered(): void27    {28        $user = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));29 30        $events = $user->releaseEvents();31 32        $this->assertCount(1, $events);33        $this->assertInstanceOf(UserRegistered::class, $events[0]);34        $this->assertSame($this->userId->value, $events[0]->userId); // událost nese primitivy35        $this->assertSame('[email protected]', $events[0]->email);36    }37 38    public function testRegistrationExposesGivenValues(): void39    {40        $user = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));41 42        $this->assertTrue($this->userId->equals($user->id));43        $this->assertTrue($this->email->equals($user->email()));44        $this->assertSame('Jan Novák', (string) $user->name());45    }46 47    public function testRenamesUser(): void48    {49        $user = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));50 51        $user->rename(new UserName('Jan Nový'));52 53        $this->assertSame('Jan Nový', (string) $user->name());54    }55 56    public function testRenameWithSameNameChangesNothing(): void57    {58        $user = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));59        $user->releaseEvents(); // vyprázdní buffer – registrace nahrála UserRegistered60 61        $user->rename(new UserName('Jan Novák'));62 63        // Idempotence: stejné jméno agregát ignoruje a nic nenahrává64        $this->assertSame('Jan Novák', (string) $user->name());65        $this->assertCount(0, $user->releaseEvents());66    }67 68    public function testChangesEmailAddress(): void69    {70        $user     = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));71        $newEmail = new Email('[email protected]');72 73        $user->changeEmail($newEmail);74 75        $this->assertTrue($newEmail->equals($user->email()));76    }77 78    public function testEmailRemainsUnchangedWhenSameValueProvided(): void79    {80        $user = User::register($this->userId, new UserName('Jan Novák'), $this->email, HashedPassword::fromPlainText('SilneHeslo123'));81        $user->releaseEvents(); // vyprázdní buffer – registrace nahrála UserRegistered82 83        $user->changeEmail(new Email('[email protected]'));84 85        // Stejný e-mail – agregát nic nezměnil a nic nenahrál86        $this->assertTrue($this->email->equals($user->email()));87        $this->assertCount(0, $user->releaseEvents());88    }89}

Testování agregátů

Agregát chrání konzistenci skupiny entit a vydává doménové události. Test agregátu proto ověřuje dvě věci: transakční invarianty (pravidla platná pro celý agregát po každé operaci) a to, že operace vydala očekávané události ve správném pořadí.

◢ Vzor

Příklad: Test pro Order agregát

php tests/Ordering/Domain/Model/OrderTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\Ordering\Domain\Model;6 7use PHPUnit\Framework\TestCase;8use App\Ordering\Domain\Model\Order;9use App\Ordering\Domain\ValueObject\OrderId;10use App\Ordering\Domain\ValueObject\CustomerId;11use App\Ordering\Domain\ValueObject\OrderStatus;12use App\Ordering\Domain\ValueObject\ProductId;13use App\SharedKernel\Domain\Money;14use App\SharedKernel\Domain\Currency;15use App\Ordering\Domain\Event\OrderPlaced;16use App\Ordering\Domain\Event\OrderConfirmed;17use App\Ordering\Domain\Event\OrderItemAdded;18use App\Ordering\Domain\Exception\EmptyOrderException;19use App\Ordering\Domain\Exception\InvalidOrderStateTransitionException;20 21final class OrderTest extends TestCase22{23    public function testAddsItemToOrder(): void24    {25        $order = Order::place(OrderId::generate(), CustomerId::generate());26 27        $order->addItem(ProductId::generate(), 2, new Money(49900, Currency::CZK));28 29        $events = $order->releaseEvents();30 31        $this->assertSame(99800, $order->totalAmount()->amountInCents); // 49 900 × 232        $this->assertSame(Currency::CZK, $order->totalAmount()->currency);33        $this->assertInstanceOf(OrderItemAdded::class, $events[1]);     // [0] je OrderPlaced34        $this->assertSame(2, $events[1]->quantity);35    }36 37    public function testThrowsExceptionWhenConfirmingEmptyOrder(): void38    {39        $order = Order::place(OrderId::generate(), CustomerId::generate());40 41        $this->expectException(EmptyOrderException::class);42 43        $order->confirm();44    }45 46    public function testConfirmsOrderSuccessfully(): void47    {48        $order = Order::place(OrderId::generate(), CustomerId::generate());49        $order->addItem(ProductId::generate(), 1, new Money(10000, Currency::CZK));50 51        $order->confirm();52 53        $this->assertSame(OrderStatus::Confirmed, $order->status);54    }55 56    public function testThrowsExceptionWhenConfirmingAlreadyConfirmedOrder(): void57    {58        $order = Order::place(OrderId::generate(), CustomerId::generate());59        $order->addItem(ProductId::generate(), 1, new Money(10000, Currency::CZK));60        $order->confirm();61 62        $this->expectException(InvalidOrderStateTransitionException::class);63 64        $order->confirm();65    }66 67    public function testReleasesRecordedEventsInOrder(): void68    {69        $order = Order::place(OrderId::generate(), CustomerId::generate());70        $order->addItem(ProductId::generate(), 1, new Money(10000, Currency::CZK));71        $order->confirm();72 73        $events = $order->releaseEvents();74 75        $this->assertCount(3, $events); // OrderPlaced + OrderItemAdded + OrderConfirmed76        $this->assertInstanceOf(OrderPlaced::class, $events[0]);77        $this->assertInstanceOf(OrderItemAdded::class, $events[1]);78        $this->assertInstanceOf(OrderConfirmed::class, $events[2]);79    }80}

17.03 Testování doménových událostí#

Doménovými událostmi agregát mluví se zbytkem systému. Test proto ověřuje přímo to, co agregát po operaci vydá: typ události, její data a pořadí během jedné transakce. Spoléhat se na vedlejší efekt event dispatcheru je křehké a do unit testu to přidává zbytečnou závislost. Pro systémy, které používají události jako zdroj pravdy, popisuje doplňující strategie testování auditovatelnosti a rebuildu projekcí kapitola Event Sourcing.

◢ Vzor

Příklad: Trait pro testování doménových událostí

php tests/Shared/Domain/DomainEventAssertions.php + tests/Ordering/Domain/Model/OrderEventsTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\Shared\Domain;6 7/**8 * Reusable trait pro ověřování doménových událostí v unit testech.9 * Použití: `use DomainEventAssertions;` ve třídě TestCase.10 *11 * Události se typují jako `object`, ne jako společná bázová třída.12 * Kanonický `AggregateRoot::record(object $event)` žádného předka13 * nevyžaduje. `DomainEvent` dědí jen události z kapitoly Event Sourcing,14 * takže vázat aserce na něj by je omezilo na tamní model.15 */16trait DomainEventAssertions17{18    /**19     * Ověří, že kolekce událostí obsahuje právě jednu událost daného typu.20     *21     * @param array<object> $events22     */23    protected function assertSingleEventOfType(string $expectedType, array $events): object24    {25        $matching = array_filter($events, fn(object $e) => $e instanceof $expectedType);26 27        $this->assertCount(28            1,29            $matching,30            sprintf('Očekávána právě jedna událost typu %s, nalezeno %d.', $expectedType, count($matching))31        );32 33        return array_values($matching)[0];34    }35 36    /**37     * Ověří, že kolekce událostí neobsahuje žádnou událost daného typu.38     *39     * @param array<object> $events40     */41    protected function assertNoEventOfType(string $unexpectedType, array $events): void42    {43        $matching = array_filter($events, fn(object $e) => $e instanceof $unexpectedType);44 45        $this->assertCount(46            0,47            $matching,48            sprintf('Neočekávána žádná událost typu %s, ale nalezena.', $unexpectedType)49        );50    }51 52    /**53     * Ověří přesné pořadí vydaných událostí.54     *55     * @param array<class-string>  $expectedTypes56     * @param array<object> $events57     */58    protected function assertEventSequence(array $expectedTypes, array $events): void59    {60        $actualTypes = array_map(fn(object $e) => $e::class, $events);61 62        $this->assertSame(63            $expectedTypes,64            $actualTypes,65            'Pořadí doménových událostí neodpovídá očekávání.'66        );67    }68}69 70// --- Druhý soubor: příklad použití traitu v testu ---71// PHPUnit hledá testy podle sufixu Test.php, proto v praxi vlastní soubor.72 73namespace App\Tests\Ordering\Domain\Model;74 75use App\Ordering\Domain\Model\Order;76use App\Ordering\Domain\ValueObject\OrderId;77use App\Ordering\Domain\ValueObject\CustomerId;78use App\Ordering\Domain\ValueObject\ProductId;79use App\SharedKernel\Domain\Money;80use App\SharedKernel\Domain\Currency;81use App\Ordering\Domain\Event\OrderPlaced;82use App\Ordering\Domain\Event\OrderConfirmed;83use App\Tests\Shared\Domain\DomainEventAssertions;84 85final class OrderEventsTest extends \PHPUnit\Framework\TestCase86{87    use DomainEventAssertions;88 89    public function testOrderPlacedEventContainsCorrectData(): void90    {91        $orderId    = OrderId::generate();92        $customerId = CustomerId::generate();93        $order      = Order::place($orderId, $customerId);94        $order->addItem(ProductId::generate(), 3, new Money(25000, Currency::CZK));95 96        $events       = $order->releaseEvents();97        $createdEvent = $this->assertSingleEventOfType(OrderPlaced::class, $events);98 99        // Ověření dat události100        $this->assertTrue($orderId->equals($createdEvent->orderId));101        $this->assertTrue($customerId->equals($createdEvent->customerId));102        $this->assertNotNull($createdEvent->occurredAt);103    }104 105    public function testNoOrderConfirmedEventWhenOrderNotConfirmed(): void106    {107        $order = Order::place(OrderId::generate(), CustomerId::generate());108        $order->addItem(ProductId::generate(), 1, new Money(10000, Currency::CZK));109 110        $events = $order->releaseEvents();111 112        $this->assertNoEventOfType(OrderConfirmed::class, $events);113    }114}

Given-when-then nad event streamem

U event-sourced agregátu je stav odvozený z historie, takže se test píše jinak. Vstupem není konstruktor, ale stream událostí: given je historie, when volání doménové metody a then události nahrané právě touto operací. Bázovou třídu EventSourcedAggregate s metodami recordEvent() a reconstituteFromEvents() definuje kapitola Event Sourcing.

Rekonstrukce z historie stav aplikuje, ale nic nenahrává – releaseEvents() po ní vrátí prázdné pole. Aserce se tedy vztahuje výhradně k tomu, co přidala testovaná operace.

◢ Vzor

Příklad: Given-when-then test event-sourced agregátu

php tests/Ordering/Domain/OrderEventSourcingTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\Ordering\Domain;6 7use PHPUnit\Framework\TestCase;8use App\Ordering\EventSourced\Order;9use App\Ordering\EventSourced\OrderItem;10use App\Ordering\EventSourced\Event\OrderConfirmed;11use App\Ordering\EventSourced\Event\OrderPlaced;12use App\Ordering\EventSourced\Event\OrderItemAdded;13use App\Ordering\EventSourced\Exception\EmptyOrderException;14use App\SharedKernel\Domain\Event\DomainEvent;15 16final class OrderEventSourcingTest extends TestCase17{18    public function testConfirmingOrderWithItemRecordsOrderConfirmed(): void19    {20        // given21        $order = $this->given(22            OrderPlaced::create('order-1', 'customer-1'),23            OrderItemAdded::create('order-1', new OrderItem(24                productId: 'product-1',25                quantity: 2,26                unitPriceInCents: 49900,27            )),28        );29 30        // when31        $order->confirm();32 33        // then34        $this->assertRecorded([OrderConfirmed::class], $order);35        $this->assertSame(3, $order->version()); // dvě historické události + jedna nová36    }37 38    public function testConfirmingEmptyOrderRecordsNothing(): void39    {40        $order = $this->given(OrderPlaced::create('order-1', 'customer-1'));41 42        try {43            $order->confirm();44            $this->fail('Očekávána EmptyOrderException.');45        } catch (EmptyOrderException) {46            // očekáváno47        }48 49        $this->assertRecorded([], $order);50    }51 52    /** given: historie streamu, ze které se agregát rekonstruuje. */53    private function given(DomainEvent ...$history): Order54    {55        return Order::reconstituteFromEvents($history);56    }57 58    /**59     * then: typy událostí nahraných až testovanou operací.60     *61     * @param array<class-string> $expected62     */63    private function assertRecorded(array $expected, Order $order): void64    {65        $actual = array_map(fn (DomainEvent $event) => $event::class, $order->releaseEvents());66 67        $this->assertSame($expected, $actual);68    }69}

Druhý test hlídá pravidlo, které stavově ukládaný agregát nemá jak porušit: neúspěšná operace nesmí nechat v bufferu událost. Kdyby confirm() nahrál OrderConfirmed ještě před kontrolou invariantu, repozitář by událost při nejbližším uložení zapsal do streamu a historie by tvrdila něco, co se nestalo.

17.04 Test doubles a InMemory repozitáře#

Test double je obecný název pro náhradu reálné závislosti v testu. Taxonomii pěti typů – dummy, stub, spy, mock a fake – zavedl Gerard Meszaros v knize xUnit Test Patterns: Refactoring Test Code (Addison-Wesley, 2007) [6]; do širšího povědomí ji dostal Fowler článkem Mocks Aren't Stubs [7]. S PHPUnit se pracuje hlavně se čtyřmi z nich (stub, mock, fake, spy). Každý vede k jinému stylu testu a k jiné odolnosti vůči refaktoringu.

§ Poznámka

Typy test doubles a jejich použití v DDD

Stub – Vrací předpřipravené odpovědi bez logiky. Hodí se, když má závislost vrátit konkrétní hodnotu, ale nezáleží na tom, zda a kolikrát se volala. Příklad: $stub->method('findById')->willReturn($user).
Mock – Stub s ověřením volání. Ověřuje, že se konkrétní metoda zavolala s konkrétními argumenty přesně n-krát. Vhodný pro ověření vedlejších efektů (volání repozitáře, odeslání e-mailu). Příklad: $mock->expects($this->once())->method('save').
Fake – Plnohodnotná, ale zjednodušená implementace rozhraní (typicky in-memory). Nezávisí na databázi, ale chová se jako skutečná implementace. Pro DDD repozitáře je to doporučená volba: testy zůstanou čitelné bez konfigurace mocků.
Méně častý je spy: podobá se mocku, ale ověřuje se až po akci (post-assertion style).

Za tímto doporučením stojí Fowlerovo rozlišení dvou způsobů ověření. State verification kontroluje stav systému po akci, behavior verification kontroluje, že proběhla očekávaná volání spolupracovníků. Z pěti typů doubles trvá na behavior verification jedině mock – ostatní obvykle vystačí s kontrolou stavu. Fake repozitář patří ke stylu, kterému Fowler říká classical TDD: reálné objekty všude, kde to jde, a doubles jen na hranicích systému.

◢ Vzor

Příklad: InMemoryUserRepository implementace

php tests/UserManagement/Infrastructure/Repository/InMemoryUserRepository.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Infrastructure\Repository;6 7use App\UserManagement\Domain\Exception\DuplicateEmailException;8use App\UserManagement\Domain\Model\User;9use App\UserManagement\Domain\ValueObject\UserId;10use App\UserManagement\Domain\ValueObject\Email;11use App\UserManagement\Domain\Repository\UserRepository;12 13/**14 * InMemory implementace UserRepository pro unit a integrační testy.15 * Simuluje chování Doctrine repozitáře bez potřeby databáze.16 */17final class InMemoryUserRepository implements UserRepository18{19    /** @var array<string, User> */20    private array $storage = [];21 22    public function save(User $user): void23    {24        // Aproximace unikátního indexu na sloupci `email`. V produkci ho25        // vymáhá databáze a handler překládá UniqueConstraintViolationException;26        // fake ho vymáhá sám, aby test nepotřeboval běžící DB.27        $existing = $this->findByEmail($user->email());28        if ($existing !== null && !$existing->id->equals($user->id)) {29            throw DuplicateEmailException::with($user->email());30        }31 32        $this->storage[(string) $user->id] = $user;33    }34 35    public function findById(UserId $id): ?User36    {37        return $this->storage[(string) $id] ?? null;38    }39 40    public function findByEmail(Email $email): ?User41    {42        foreach ($this->storage as $user) {43            if ($user->email()->equals($email)) {44                return $user;45            }46        }47 48        return null;49    }50 51    public function remove(User $user): void52    {53        unset($this->storage[(string) $user->id]);54    }55 56    /** Pomocná metoda pro aserce v testech. */57    public function count(): int58    {59        return count($this->storage);60    }61 62    /** @return array<User> */63    public function all(): array64    {65        return array_values($this->storage);66    }67}

◢ Vzor

Příklad: Test command handleru s InMemoryRepository

php tests/UserManagement/Registration/Command/RegisterUserHandlerTest.php (varianta s InMemoryRepository)

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Registration\Command;6 7use Doctrine\ORM\EntityManagerInterface;8use PHPUnit\Framework\TestCase;9use Symfony\Component\Messenger\Envelope;10use Symfony\Component\Messenger\MessageBusInterface;11use App\UserManagement\Registration\Command\RegisterUser;12use App\UserManagement\Registration\Command\RegisterUserHandler;13use App\UserManagement\Domain\Exception\DuplicateEmailException;14use App\UserManagement\Domain\ValueObject\Email;15use App\Tests\UserManagement\Infrastructure\Repository\InMemoryUserRepository;16 17final class RegisterUserHandlerTest extends TestCase18{19    private InMemoryUserRepository $userRepository;20    private RegisterUserHandler $handler;21 22    protected function setUp(): void23    {24        $this->userRepository = new InMemoryUserRepository();25        // Handler volá flush() kvůli překladu unique violation. Fake repozitář26        // ho neřeší, takže EntityManager stačí jako stub, který nedělá nic.27        //28        // Pozor na hranici toho testu: fake vyhazuje DuplicateEmailException29        // rovnou ze save(), zatímco produkce ji dostane až z flush() jako30        // UniqueConstraintViolationException a handler ji teprve překládá.31        // Test tedy ověřuje reakci handleru na výjimku, ne ten překlad.32        // Na překlad je potřeba integrační test proti skutečné databázi.33        //34        // Event bus je také stub. dispatch() má návratový typ Envelope a ta je35        // final, takže ji PHPUnit neumí podvrhnout automaticky – bez willReturn()36        // by stub vrátil null a volání spadlo na TypeError. Co handler odešle,37        // tento test neověřuje; na to je messenger-test níže v kapitole.38        $eventBus = $this->createStub(MessageBusInterface::class);39        $eventBus->method('dispatch')->willReturn(new Envelope(new \stdClass()));40 41        $this->handler = new RegisterUserHandler(42            $this->userRepository,43            $this->createStub(EntityManagerInterface::class),44            $eventBus,45        );46    }47 48    public function testRegistersNewUser(): void49    {50        $command = new RegisterUser(51            name: 'Jan Novák',52            email: '[email protected]',53            password: 'SilneHeslo123!'54        );55 56        ($this->handler)($command);57 58        $this->assertSame(1, $this->userRepository->count());59 60        $user = $this->userRepository->findByEmail(new Email('[email protected]'));61        $this->assertNotNull($user);62        $this->assertSame('[email protected]', $user->email()->value);63        $this->assertSame('Jan Novák', (string) $user->name());64    }65 66    public function testNormalizesEmailBeforeRegistration(): void67    {68        $command = new RegisterUser(name: 'Jan Novák', email: '[email protected]', password: 'SilneHeslo123');69 70        ($this->handler)($command);71 72        // Handler prošel vstup přes Email::fromUserInput(), uložený e-mail je malými písmeny73        $this->assertNotNull($this->userRepository->findByEmail(new Email('[email protected]')));74    }75 76    public function testThrowsExceptionWhenEmailAlreadyTaken(): void77    {78        $command = new RegisterUser(name: 'Jan Novák', email: '[email protected]', password: 'SilneHeslo123');79        ($this->handler)($command); // první registrace80 81        $this->expectException(DuplicateEmailException::class);82 83        ($this->handler)($command); // duplicitní registrace84    }85 86    public function testDoesNotPersistUserWhenEmailAlreadyTaken(): void87    {88        $command = new RegisterUser(name: 'Jan Novák', email: '[email protected]', password: 'SilneHeslo123');89        ($this->handler)($command);90 91        try {92            ($this->handler)($command);93        } catch (DuplicateEmailException) {94            // očekáváno95        }96 97        $this->assertSame(1, $this->userRepository->count());98    }99}

InMemory repozitář zde unikátnost e-mailu jen aproximuje: kontroluje ji v paměti a rovnou hází DuplicateEmailException. Finální záruku dává unikátní constraint v databázi – kanonický handler překládá jeho porušení na tutéž výjimku (viz race condition v naivní variantě). Test ověřuje chování handleru, ne řešení souběhu, proto EntityManager stačí jako stub.

Testovací data: builder místo opakovaného konstruktoru

Testy v předchozích ukázkách opakují v každé metodě totéž volání User::register($id, new UserName('Jan Novák'), $email, HashedPassword::fromPlainText('SilneHeslo123')). Pro test je z něj podstatný jeden argument, zbytek je tam proto, že ho vyžaduje konstruktor. Až přibude pátý parametr, mění se všechny testy naráz.

Řešením je Test Data Builder od Steva Freemana a Nata Pryce z knihy Growing Object-Oriented Software, Guided by Tests (Addison-Wesley, 2009) [8]. Builder má pole pro každý parametr konstruktoru, inicializované bezpečnou hodnotou, řetězitelné metody pro přepsání těchto polí a metodu build(), která z nich složí cílový objekt. Volitelně přidá statickou tovární metodu, aby bylo v testu na první pohled zřejmé, co se staví; autoři ji ukazují právě na OrderBuilder s metodou anOrder(). Přínos shrnují do tří bodů: builder obalí syntaktický šum kolem vytváření objektů, výchozí případ udrží jednoduchý a zvláštní jen o málo složitější a odstíní testy od změny struktury objektu – po přidání parametru se mění jediné místo.

◢ Vzor

Příklad: Test Data Builder pro Order agregát

php tests/Ordering/Domain/Builder/OrderBuilder.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\Ordering\Domain\Builder;6 7use App\Ordering\Domain\Model\Order;8use App\SharedKernel\Domain\Currency;9use App\Ordering\Domain\ValueObject\CustomerId;10use App\SharedKernel\Domain\Money;11use App\Ordering\Domain\ValueObject\OrderId;12use App\Ordering\Domain\ValueObject\ProductId;13 14final class OrderBuilder15{16    private OrderId $orderId;17    private CustomerId $customerId;18 19    /** @var list<array{ProductId, int, Money}> */20    private array $items = [];21 22    private bool $confirmed = false;23 24    private function __construct()25    {26        // Bezpečné výchozí hodnoty – test nastavuje jen to, na čem mu záleží27        $this->orderId    = OrderId::generate();28        $this->customerId = CustomerId::generate();29    }30 31    public static function anOrder(): self32    {33        return new self();34    }35 36    public function forCustomer(CustomerId $customerId): self37    {38        $this->customerId = $customerId;39 40        return $this;41    }42 43    public function withItem(int $quantity = 1, ?Money $unitPrice = null): self44    {45        $this->items[] = [46            ProductId::generate(),47            $quantity,48            $unitPrice ?? new Money(49900, Currency::CZK),49        ];50 51        return $this;52    }53 54    public function confirmed(): self55    {56        $this->confirmed = true;57 58        return $this;59    }60 61    public function build(): Order62    {63        $order = Order::place($this->orderId, $this->customerId);64 65        // Objednávka bez položek nejde potvrdit, výchozí položka je proto bezpečná hodnota66        $items = $this->items !== []67            ? $this->items68            : [[ProductId::generate(), 1, new Money(49900, Currency::CZK)]];69 70        foreach ($items as [$productId, $quantity, $unitPrice]) {71            $order->addItem($productId, $quantity, $unitPrice);72        }73 74        if ($this->confirmed) {75            $order->confirm();76        }77 78        return $order;79    }80}81 82/*83 * Použití v testu – patří dovnitř testovací metody. Kdyby ty řádky84 * zůstaly na úrovni souboru, PHP je vykoná při autoloadu třídy85 * a každý test s builderem by navíc postavil jednu objednávku bokem.86 *87 * $order = OrderBuilder::anOrder()88 *     ->forCustomer(CustomerId::generate())89 *     ->withItem(quantity: 3, unitPrice: new Money(25000, Currency::CZK))90 *     ->confirmed()91 *     ->build();92 *93 * // stavba agregátu vydala události, test si buffer vyprázdní94 * $order->releaseEvents();95 */

Builder je mutabilní, takže každý test si volá anOrder() znovu; sdílená instance mezi testy je zdrojem těžko dohledatelných závislostí na pořadí.

Starší příbuzný vzor je Object Mother (Peter Schuh, Stephanie Punke, ObjectMother: Easing Test Object Creation In XP, XP Universe, 2001): pojmenovaná tovární metoda vrátí hotovou fixturu, například OrderMother::confirmedOrder(). Čte se dobře, dokud variant nepřibývá. Fowler mu vyčítá dvě věci [9]: mnoho testů se váže na přesná data jedné fixtury a po změně tříd je potřeba migrovat všechny mothers najednou. Builder tento tlak rozpouští tím, že variantu skládá volající.

Fixtury, které mají skončit v databázi, řeší v Symfony zenstruck/foundry [10]. Zápis OrderFactory::new()->confirmed()->create() je týž vzor obalený integrací na Doctrine. Doménové unit testy persistenci nepotřebují a vystačí si s builderem; factory patří do integračních a funkčních testů z následujících dvou sekcí.

17.05 Integrační testy s Doctrine#

Integrační testy odpovídají na otázku, kterou unit testy pokrýt nemohou: zda Doctrine mapování, dotazy repozitářů a transakce skutečně dělají to, co jejich rozhraní slibuje. Výchozí volbou je stejný databázový engine jako v produkci, spuštěný v kontejneru. SQLite in-memory je rychlejší, ale liší se typovým systémem, chováním unikátních constraintů i transakční sémantikou, tedy přesně v tom, co má integrační test ověřit. Zůstává vědomou zkratkou pro rychlou zpětnou vazbu při lokálním vývoji, ne konfigurací, na které stojí CI.

Doctrine i InMemory implementace přitom plní tutéž smlouvu rozhraní: findById(UserId $id): ?User vrací při nenalezení null, stejně jako InMemory varianta ze sekce o test doubles. Kniha drží obě konvence, každou pro jiný případ. Command handler, který agregát podle identity nutně potřebuje, volá get() a při nenalezení dostane doménovou výjimku (OrderNotFoundException::withId() z Domain\Exception). Návrat null zůstává metodám find…() tam, kde absence chybou není, například findByEmail() při registraci.

Bundle potřebuje dvě registrace: v config/bundles.php (viz Konfigurace a spouštění) a v konfiguraci PHPUnitu jako bootstrap extension:

◢ Vzor

Příklad: Registrace DAMA extension v phpunit.dist.xml

xml phpunit.dist.xml (výřez: extensions)

1<extensions>2    <bootstrap class="DAMA\DoctrineTestBundle\PHPUnit\PHPUnitExtension"/>3</extensions>

◢ Vzor

Příklad: Integrační test DoctrineUserRepository

php tests/UserManagement/Infrastructure/Repository/DoctrineUserRepositoryTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Infrastructure\Repository;6 7use Symfony\Bundle\FrameworkBundle\Test\KernelTestCase;8use App\UserManagement\Domain\Model\User;9use App\UserManagement\Domain\ValueObject\UserId;10use App\UserManagement\Domain\ValueObject\Email;11use App\UserManagement\Domain\ValueObject\HashedPassword;12use App\UserManagement\Domain\ValueObject\UserName;13use App\UserManagement\Infrastructure\Repository\DoctrineUserRepository;14use Doctrine\ORM\EntityManagerInterface;15 16/**17 * Integrační test pro DoctrineUserRepository.18 * Vyžaduje běžící databázi (konfigurovanou přes DATABASE_URL v .env.test).19 * Transakční rollback zajišťuje dama/doctrine-test-bundle.20 *21 * Repozitář se bere přímo z kontejneru, takže musí být v test prostředí22 * public – viz services_test.yaml pod ukázkou. Privátní službu, kterou23 * kompilace odstraní, testovací kontejner nevydá a get() skončí24 * ServiceNotFoundException.25 */26final class DoctrineUserRepositoryTest extends KernelTestCase27{28    private EntityManagerInterface $entityManager;29    private DoctrineUserRepository $repository;30 31    protected function setUp(): void32    {33        self::bootKernel();34 35        $this->entityManager = self::getContainer()->get('doctrine')->getManager();36        $this->repository    = self::getContainer()->get(DoctrineUserRepository::class);37    }38 39    public function testPersistsAndRetrievesUser(): void40    {41        $userId = UserId::generate();42        $email  = new Email('[email protected]');43        $user   = User::register($userId, new UserName('Test Uživatel'), $email, HashedPassword::fromPlainText('SilneHeslo123'));44 45        $this->repository->save($user);46        // save() jen persistuje; zápis do DB spouští až flush(). Vlastníkem47        // flushe je v této knize handler, takže si ho test musí zavolat sám.48        $this->entityManager->flush();49        $this->entityManager->clear(); // vyčistí identity map – jinak by čtení nešlo do DB50 51        $retrieved = $this->repository->findById($userId);52 53        $this->assertNotNull($retrieved);54        $this->assertTrue($userId->equals($retrieved->id));55        $this->assertTrue($email->equals($retrieved->email()));56    }57 58    public function testReturnsNullForNonExistentUser(): void59    {60        $this->assertNull($this->repository->findById(UserId::generate()));61    }62 63    public function testFindsByEmailAddress(): void64    {65        $email = new Email('[email protected]');66        $user  = User::register(UserId::generate(), new UserName('Test Uživatel'), $email, HashedPassword::fromPlainText('SilneHeslo123'));67 68        $this->repository->save($user);69        $this->entityManager->flush();70        $this->entityManager->clear();71 72        $found = $this->repository->findByEmail($email);73 74        $this->assertNotNull($found);75        $this->assertTrue($email->equals($found->email()));76    }77 78    public function testFindByEmailSeesUserOnlyAfterFlush(): void79    {80        $email = new Email('[email protected]');81        $user  = User::register(UserId::generate(), new UserName('Test Uživatel'), $email, HashedPassword::fromPlainText('SilneHeslo123'));82 83        // findOneBy() se ptá databáze; persistovaný, ale nezapsaný User v ní ještě není.84        $this->repository->save($user);85        $this->assertNull($this->repository->findByEmail($email));86 87        $this->entityManager->flush();88 89        $this->assertNotNull($this->repository->findByEmail($email));90    }91}

Testovací kontejner (static::getContainer()) vydá i privátní služby, ale jen ty, které kompilace neodstranila. Služba, kterou žádná jiná přímo nepoužívá, v něm chybí a get() na ní selže. Test, který sahá po konkrétní implementaci, si ji proto v test prostředí zveřejní:

yaml config/services_test.yaml

1services:2    # _defaults se mezi soubory nedědí. Bez něj tahle definice nahradí tu3    # ze services.yaml celou, služba se postaví bez argumentů a testy4    # spadnou na ArgumentCountError místo na ServiceNotFoundException.5    _defaults:6        autowire: true7        autoconfigure: true8 9    # Jen pro testy. V produkci zůstává služba privátní a chodí se na ni10    # přes injektované rozhraní UserRepository.11    App\UserManagement\Infrastructure\Repository\DoctrineUserRepository:12        public: true

17.06 Funkční testy API a kontrolerů#

Funkční test prochází celý zásobník: request přijde do kontroleru, projde aplikační vrstvou, dotkne se databáze a vrátí odpověď. Ověřuje se HTTP status kód, tělo (typicky JSON), hlavičky a chování při chybových vstupech. V DDD je to jediná vrstva testů, která ověří, že prezentační a aplikační vrstva spolu opravdu fungují.

§ Poznámka

WebTestCase v Symfony

Symfony\Bundle\FrameworkBundle\Test\WebTestCase poskytuje metodu createClient(), která vrátí HTTP klienta simulujícího prohlížeč. Klient odesílá requesty GET, POST, PUT, PATCH a DELETE. Response obsahuje status kód, tělo a hlavičky – vše přímo assertovatelné.

Vedle obecného assertResponseStatusCodeSame() nabízí framework desítky pojmenovaných assertů (assertResponseIsSuccessful(), assertResponseIsUnprocessable(), assertResponseRedirects(), asserty nad odeslanými e-maily a zprávami Messengeru). Jejich úplný seznam je v dokumentaci Symfony [12]. Na rozdíl od holého assertSame() nad status kódem vypíšou asserty frameworku při selhání i odpověď, takže se ladí bez dodatečného dump().

◢ Vzor

Příklad: Funkční test registračního endpointu

php tests/UserManagement/Registration/Controller/RegistrationControllerTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Registration\Controller;6 7use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;8 9/**10 * Funkční testy registračního REST API endpointu.11 * Testují HTTP vrstvu + celý zásobník až po databázi.12 */13final class RegistrationControllerTest extends WebTestCase14{15    public function testRegistersUserSuccessfully(): void16    {17        $client = static::createClient();18 19        $client->request(20            method: 'POST',21            uri: '/api/register',22            server: ['CONTENT_TYPE' => 'application/json'],23            content: json_encode([24                'name'     => 'Jan Novák',25                'email'    => '[email protected]',26                'password' => 'SilneHeslo123!',27            ])28        );29 30        $this->assertResponseStatusCodeSame(201);31        $this->assertResponseHeaderSame('Content-Type', 'application/json');32 33        // Command nic nevrací, takže kontroler potvrdí jen vytvoření.34        $responseData = json_decode($client->getResponse()->getContent(), true);35 36        $this->assertSame(['status' => 'created'], $responseData);37    }38 39    public function testReturns422ForInvalidEmail(): void40    {41        $client = static::createClient();42 43        $client->request(44            method: 'POST',45            uri: '/api/register',46            // Bez Accept by chybu 422 vykreslila HTML stránka, ne JSON.47            server: ['CONTENT_TYPE' => 'application/json', 'HTTP_ACCEPT' => 'application/json'],48            content: json_encode([49                'name'     => 'Jan Novák',50                'email'    => 'not-valid-email',51                'password' => 'SilneHeslo123',52            ])53        );54 55        $this->assertResponseIsUnprocessable();56 57        // Tělo má strukturu Problem Details (RFC 7807), porušení nese klíč `violations`.58        $responseData = json_decode($client->getResponse()->getContent(), true);59 60        $this->assertArrayHasKey('violations', $responseData);61        $this->assertSame('email', $responseData['violations'][0]['propertyPath']);62    }63 64    public function testReturns409WhenEmailAlreadyRegistered(): void65    {66        $client = static::createClient();67 68        $payload = json_encode(['name' => 'Jan Novák', 'email' => '[email protected]', 'password' => 'SilneHeslo123!']);69 70        $client->request('POST', '/api/register',71            server: ['CONTENT_TYPE' => 'application/json'],72            content: $payload73        );74        $this->assertResponseStatusCodeSame(201);75 76        // druhý pokus se stejným emailem77        $client->request('POST', '/api/register',78            server: ['CONTENT_TYPE' => 'application/json'],79            content: $payload80        );81        $this->assertResponseStatusCodeSame(409);82    }83 84    public function testReturns422ForMissingRequiredFields(): void85    {86        $client = static::createClient();87 88        $client->request(89            method: 'POST',90            uri: '/api/register',91            server: ['CONTENT_TYPE' => 'application/json'],92            content: json_encode([])93        );94 95        // Chybějící argumenty konstruktoru serializer sesbírá jako porušení,96        // takže odpověď je 422 stejně jako u neplatného formátu, ne 400.97        $this->assertResponseIsUnprocessable();98    }99}

17.07 Testování asynchronních toků#

Asynchronní zpracování přes Messenger rozděluje tok na dvě poloviny: odeslání zprávy a její zpracování workerem. Test musí pokrýt obě, každou zvlášť. Architekturu busů popisuje kapitola CQRS, transakční předávání zpráv kapitola Outbox Pattern.

In-memory transport

V testovacím prostředí nahradí reálný broker transport in-memory://. Zprávy nikam neodcházejí, zůstávají v paměti procesu a test si je vyzvedne přímo z kontejneru. Stačí přepsat DSN transportu pro prostředí test:

◢ Vzor

Příklad: In-memory transport pro testy

yaml config/packages/test/messenger.yaml

1framework:2    messenger:3        transports:4            async_commands: 'in-memory://'5            async_events: 'in-memory://'

Ukázky v této sekci počítají s posluchačem UserRegistered, který na command.bus odešle příkaz SendWelcomeEmail. Příkaz směruje řádek App\UserManagement\Application\Message\SendWelcomeEmail: async_commands doplněný do framework.messenger.routing z kapitoly CQRS.

Transport vystavuje getSent(), getAcknowledged() a reset(). Úklid ale obstará framework: v testech dědících z KernelTestCase nebo WebTestCase se všechny in-memory transporty po každém testu resetují samy [13]. Volba serialize (v DSN in-memory://?serialize=true) navíc zprávy protáhne serializační vrstvou, takže se otestuje i to, co se v produkci posílá po drátě.

Funkční test pak ověří, že endpoint zprávu skutečně odeslal, aniž by čekal na workera:

◢ Vzor

Příklad: Aserce nad odeslanými zprávami

php tests/UserManagement/Functional/RegisterUserDispatchTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Functional;6 7use App\UserManagement\Application\Message\SendWelcomeEmail;8use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;9 10final class RegisterUserDispatchTest extends WebTestCase11{12    public function testRegistrationDispatchesWelcomeEmail(): void13    {14        $client = static::createClient();15 16        $client->request(17            method: 'POST',18            uri: '/api/register',19            server: ['CONTENT_TYPE' => 'application/json'],20            content: json_encode(['name' => 'Jan Novák', 'email' => '[email protected]', 'password' => 'SilneHeslo123!'])21        );22 23        $transport = self::getContainer()->get('messenger.transport.async_commands');24        $sent      = $transport->getSent();25 26        $this->assertCount(1, $sent);27        $this->assertInstanceOf(SendWelcomeEmail::class, $sent[0]->getMessage());28    }29}

zenstruck/messenger-test

Holé aserce nad transportem fungují, ale v každém testu se opakují. Balíček zenstruck/messenger-test je zabalí do čitelného API: trait InteractsWithMessenger zpřístupní frontu transportu a metoda process() zpracuje zařazené zprávy přímo v testu, bez spouštění workera.

Balíček přináší vlastní transport a trvá na svém DSN. Nad in-memory:// trait nefunguje, konfigurace z předchozí ukázky se proto pro tento styl testů přepíše na test:// [14]:

◢ Vzor

Příklad: Transport pro zenstruck/messenger-test

yaml config/packages/test/messenger.yaml

1framework:2    messenger:3        transports:4            # DSN test:// vyžaduje trait InteractsWithMessenger; volitelné parametry5            # se předávají v query stringu, například test://?catch_exceptions=false6            async_commands: 'test://'7            async_events: 'test://'

Obě konfigurace jsou alternativy, ne vrstvy: transport má v daném prostředí jedno DSN. Sada, která zůstane u in-memory://, si vystačí s getSent(); sada postavená na zenstruck jde na test:// a aserce píše přes trait.

◢ Vzor

Příklad: Test celého asynchronního toku se zenstruck/messenger-test

php tests/UserManagement/Functional/RegisterUserFlowTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Functional;6 7use App\UserManagement\Application\Message\SendWelcomeEmail;8use Symfony\Bundle\FrameworkBundle\Test\WebTestCase;9use Zenstruck\Messenger\Test\InteractsWithMessenger;10 11final class RegisterUserFlowTest extends WebTestCase12{13    use InteractsWithMessenger;14 15    public function testRegistrationQueuesAndProcessesWelcomeEmail(): void16    {17        $client = static::createClient();18 19        $client->request(20            method: 'POST',21            uri: '/api/register',22            server: ['CONTENT_TYPE' => 'application/json'],23            content: json_encode([24                'name'     => 'Jan Novák',25                'email'    => '[email protected]',26                'password' => 'SilneHeslo123!',27            ], JSON_THROW_ON_ERROR),28        );29 30        $this->transport('async_commands')->queue()->assertCount(1);31        $this->transport('async_commands')->queue()->assertContains(SendWelcomeEmail::class);32 33        $this->transport('async_commands')->process();      // zpracuje frontu v testu34        $this->transport('async_commands')->queue()->assertEmpty();35    }36}

Test idempotence handleru

Asynchronní transport doručuje zprávy v režimu at-least-once: po pádu workera dorazí tatáž zpráva podruhé. Handler proto musí být idempotentní: dvojí zpracování smí vyvolat jen jeden efekt. Deduplikační mechanismus popisuje Idempotent Inbox, kde se záznam ukládá pod dvojicí eventId (UUID v7) a consumer. Test je krátký: zavolá handler dvakrát se stejnou zprávou a spočítá efekty.

◢ Vzor

Příklad: Test idempotence handleru

php tests/UserManagement/Application/SendWelcomeEmailHandlerTest.php

1<?php2 3declare(strict_types=1);4 5namespace App\Tests\UserManagement\Application;6 7use App\Tests\Double\InMemoryInboxRepository;8use App\Tests\Double\SpyMailer;9use App\UserManagement\Application\Message\SendWelcomeEmail;10use App\UserManagement\Application\MessageHandler\SendWelcomeEmailHandler;11use PHPUnit\Framework\TestCase;12use Symfony\Component\Uid\Uuid;13 14final class SendWelcomeEmailHandlerTest extends TestCase15{16    public function testHandlesDuplicateDeliveryOnce(): void17    {18        $mailer  = new SpyMailer();19        $handler = new SendWelcomeEmailHandler($mailer, new InMemoryInboxRepository());20 21        $message = new SendWelcomeEmail(22            eventId: Uuid::fromString('0190a5c2-7b3e-7d4a-9c1e-5f2b8a6d4e10'),23            email: '[email protected]',24        );25 26        ($handler)($message);27        ($handler)($message); // opakované doručení téže zprávy28 29        $this->assertSame(1, $mailer->sentCount());30    }31}

Test outboxu

Outbox dává dvě garance a každá potřebuje vlastní integrační test. První: po flush() leží událost v outbox tabulce, zapsaná ve stejné transakci jako agregát. Druhá: relay ji publikuje do transportu a označí jako odeslanou (sent). Obě varianty relay procesu rozebírá kapitola o Outbox Pattern.

◢ Vzor

Příklad: Integrační testy outboxu (KernelTestCase)

Test níže staví na Outboxu z kapitoly Outbox Pattern – potřebuje PlaceOrderHandler, OutboxRepository a příkaz relaye odtud. Ukázka je proto výřez dvou metod, ne celý soubor; setUp() si služby vytáhne z kontejneru.

php tests/Ordering/Infrastructure/OutboxFlowTest.php (dvě testovací metody)

1public function testFlushWritesEventToOutbox(): void2{3    ($this->placeOrderHandler)(new PlaceOrder(/* ... */));4 5    $pending = $this->outboxRepository->fetchPending(limit: 10);6 7    $this->assertCount(1, $pending);8    // message_type nese FQCN integrační události, ne vlastní alias9    $this->assertSame(OrderPlacedIntegrationEvent::class, $pending[0]->messageType);10}11 12public function testRelayPublishesPendingEvents(): void13{14    ($this->placeOrderHandler)(new PlaceOrder(/* ... */));15 16    $tester = new CommandTester($this->outboxDispatchCommand);17    // Bez limitu by smyčka relaye běžela hodinu (výchozí --time-limit=3600)18    $tester->execute(['--time-limit' => 1]);19 20    // Relay posílá na transport async_events (TransportNamesStamp v 15.05);21    // v prostředí test má DSN in-memory:// z konfigurace výše22    $transport = self::getContainer()->get('messenger.transport.async_events');23 24    $this->assertCount(1, $transport->getSent());25    $this->assertCount(0, $this->outboxRepository->fetchPending(limit: 10));26}

Druhý test záměrně končí dvojicí asercí: zpráva odešla a fronta pending záznamů je prázdná. Kdyby relay publikoval, ale neoznačil záznam jako odeslaný, příští běh by událost poslal znovu.

17.08 Architektonické testy#

Pravidlo, že doménová vrstva nesmí záviset na infrastruktuře ani na aplikační vrstvě, drží jen do prvního uspěchaného code review, ve kterém někdo do entity natáhne repozitář z Infrastructure. Architektonické testy tomu brání technicky: pravidla závislostí se popíšou deklarativně a porušení padne v CI jako spadlý test, ne až v review.

Deptrac

Deptrac analyzuje závislosti staticky. Konfigurace popisuje vrstvy (layers) a povolená pravidla mezi nimi (ruleset), nástroj projde kód a vypíše porušení. V CI běží jako samostatný krok vedle statické analýzy.

Na historii balíčku záleží, protože podle ní se hledá dokumentace. Projekt vznikl v sensiolabs-de, pokračoval pod hlavičkou QOSSMIC a dnes má vlastní organizaci. Balíček qossmic/deptrac je na Packagistu označený jako abandoned a nahradil ho deptrac/deptrac [15]. Řada 4.x drží konfiguraci ve výchozím souboru deptrac.php s typovaným API; YAML zůstává podporovaný, ale vendor/bin/deptrac init generuje PHP.

◢ Vzor

Příklad: deptrac.php konfigurace pro DDD projekt

php deptrac.php

1<?php2 3declare(strict_types=1);4 5use Deptrac\Deptrac\Contract\Config\Collector\DirectoryConfig;6use Deptrac\Deptrac\Contract\Config\DeptracConfig;7use Deptrac\Deptrac\Contract\Config\Layer;8use Deptrac\Deptrac\Contract\Config\Ruleset;9 10return static function (DeptracConfig $config): void {11    // Baseline se načte jen tehdy, když existuje. Bezpodmínečný zápis shodí12    // i ten příkaz, kterým se baseline teprve vytváří - a čtenář uvízne13    // hned na prvním spuštění.14    if (file_exists(__DIR__ . '/deptrac.baseline.yaml')) {15        $config->baseline('deptrac.baseline.yaml');16    }17 18    $config19        ->paths('./src')20        ->layers(21            // Negativní lookahead je nutný: 'src/.*/Domain/.*' pohltí22            // i src/SharedKernel/Domain a Deptrac pak hlásí tytéž třídy23            // ve dvou vrstvách zároveň.24            $domain = Layer::withName('Domain')->collectors(25                DirectoryConfig::create('src/(?!SharedKernel)[^/]+/Domain/.*'),26                // Event-sourced model má vlastní namespace, jinak zůstane nepokrytý27                DirectoryConfig::create('src/[^/]+/EventSourced/.*')28            ),29            $application = Layer::withName('Application')->collectors(30                DirectoryConfig::create('src/.*/Application/.*'),31                // use-case slice mimo Application/ - handlery typu32                // App\UserManagement\Registration\Command\RegisterUserHandler33                DirectoryConfig::create('src/.*/Registration/Command/.*')34            ),35            $infrastructure = Layer::withName('Infrastructure')->collectors(36                DirectoryConfig::create('src/.*/Infrastructure/.*'),37                // Sdílená infrastruktura leží o úroveň výš než kontexty38                DirectoryConfig::create('src/Infrastructure/.*')39            ),40            $presentation = Layer::withName('Presentation')->collectors(41                DirectoryConfig::create('src/.*/Controller/.*')42            ),43            $shared = Layer::withName('Shared')->collectors(44                DirectoryConfig::create('src/SharedKernel/.*')45            ),46        )47        ->rulesets(48            // Doménová vrstva sahá jen na Shared49            Ruleset::forLayer($domain)->accesses($shared),50            // Aplikační vrstva stojí na doméně a sdílených komponentách51            Ruleset::forLayer($application)->accesses($domain, $shared),52            // Infrastruktura implementuje doménová rozhraní53            Ruleset::forLayer($infrastructure)->accesses($domain, $application, $shared),54            // Kontrolery mluví s aplikační vrstvou (commands, queries). Na doménu55            // smějí kvůli doménovým výjimkám, které překládají na HTTP status.56            Ruleset::forLayer($presentation)->accesses($application, $domain, $shared),57            // Shared nezávisí na ničem projektovém - ruleset bez accesses()58            Ruleset::forLayer($shared),59        )60    ;61};

V novém projektu drží pravidlo od prvního commitu. Do existující kódové báze se dostane jen přes baseline: analyse --formatter=baseline zapíše současná porušení do deptrac.baseline.yaml, konfigurace ho načte a build zůstane zelený. Nová porušení pak selžou, stará se odbourávají postupně. Bez baseline skončí první spuštění stovkou chyb a pravidlo se z CI zase vyhodí.

◢ Vzor

Příklad: Spuštění Deptrac v CI

bash snippet.sh

1# Instalace (dev závislost)2composer require --dev deptrac/deptrac3 4# Vygenerování šablony konfigurace5vendor/bin/deptrac init6 7# Spuštění analýzy nad výchozím deptrac.php8vendor/bin/deptrac analyse9 10# Jednorázově při zavádění: zapsat současná porušení do baseline11vendor/bin/deptrac analyse --formatter=baseline12 13# Výstup v případě porušení:14# [ERROR] Found 1 Violation15# App\UserManagement\Domain\Model\User must not depend on16# App\UserManagement\Infrastructure\Repository\DoctrineUserRepository (Infrastructure)

phparkitect jako alternativa

Pravidla závislostí umí vynutit i phparkitect (phparkitect/phparkitect) [16]. Pracuje na jiné úrovni než Deptrac: místo vrstev popisuje pravidla nad jednotlivými třídami, jejich namespace a názvy a zapisuje je do souboru phparkitect.php. Nástroj má vlastní CLI, nespouští se přes PHPUnit a v CI běží jako samostatný krok vedle testovací sady. Instalaci a přehled pravidel uvádí kapitola Doplňující taktické vzory; plnou konfiguraci pro modulární monolit ukazuje kapitola DDD a microservices. Zde stačí zapojení do pipeline:

◢ Vzor

Příklad: Spuštění phparkitect v CI

bash snippet.sh

1composer require --dev phparkitect/phparkitect2 3# Samostatný krok CI pipeline vedle PHPUnit a Deptrac4vendor/bin/phparkitect check5 6# Zavádění do existujícího projektu: zmrazit současná porušení7vendor/bin/phparkitect generate-baseline   # zapíše phparkitect-baseline.json8vendor/bin/phparkitect prune-baseline      # odstraní z baseline už opravená porušení

Volba mezi oběma nástroji je věcí preferencí týmu. Deptrac popisuje vrstvy a hodí se pro plošná pravidla mezi nimi; phparkitect dovolí jemnější pravidla nad jednotlivými třídami (suffixy názvů, konkrétní namespace). Oba selžou v CI stejně – jako spadlý build. Projekty, které používají Pest, mají třetí možnost: vestavěné arch() API zapisuje totéž pravidlo jako arch('domain')->expect('App\Domain')->not->toUse('App\Infrastructure') a běží rovnou uvnitř testovací sady [17].

17.09 Code coverage a doporučené postupy#

Code coverage měří, jaké procento řádků kódu se při běhu testů provede. Sama metrika nic neříká o kvalitě testů: 100% pokrytí lze dosáhnout testy, které jen volají metody bez asercí. Užitečná je ale opačně: kde je pokrytí nízké, leží kód, který nikdo netestuje, a tam se vyplatí podívat.

§ Poznámka

Pokrytí po vrstvách – co kde testovat

Doménová vrstva (Domain) – testuje se beze zbytku. Leží tu veškerá doménová logika a každý invariant, každá validace i každé pravidlo má mít vlastní test. Nepokrytý řádek v doméně je otázka, ne statistika.
Aplikační vrstva (Application) – unit testy handlerů s InMemory repozitáři. Nepokryté zůstávají hlavně technické větve: logování, mapování výjimek na HTTP kódy.
Infrastrukturní vrstva (Infrastructure) – integrační testy tam, kde je vlastní kód. Dotazy repozitářů, konverze typů a klienti externích API test potřebují; vygenerované Doctrine mapování ne.
Prezentační vrstva (Presentation) – funkční testy hlavního scénáře a nejdůležitějších chybových cest.

Konkrétní cílové procento tato kniha nedoporučuje. Žádný z kanonických zdrojů takové číslo nestanovuje a metrika sama o kvalitě testů nevypovídá. Užitečný je trend: propad pokrytí domény mezi dvěma sprinty znamená, že do ní něco přibylo bez testu.

! Pozor

Nejčastější chyby při testování DDD

Testování getterů místo chování – Špatně: $this->assertSame('[email protected]', $user->getEmail()) po přímém nastavení vlastnosti. Správně: zavolat doménovou operaci a ověřit výsledný stav.
Přímý přístup k privátním vlastnostem přes reflexi – Porušuje zapouzdření. Potřeba sahat v testu na privátní stav je příznak špatného návrhu API třídy.
Bootstrapování celého Symfony kernelu v unit testech – Zpomaluje sadu testů. Unit testy doménové vrstvy nesmí volat self::bootKernel(), bootstrap kernelu patří do integračních testů.
Sdílený stav mezi testy – Každý test musí být nezávislý. Sdílené statické proměnné nebo globální stav způsobují nestabilní (flaky) testy, jejichž výsledek závisí na pořadí spouštění.
Mockování value objects – Value objekty jsou datové třídy bez závislostí. Není důvod je mockovat; test pracuje se skutečnou instancí.
Ignorování doménových výjimek v testech – Každá doménová výjimka (EmptyOrderException, InvalidOrderStateTransitionException apod.) musí mít test ověřující, že ji kód vyhodí za správných podmínek.
Chybějící test pro releaseEvents() po operaci – Pokud agregát vydává doménové události, musí mít každá veřejná operace, která událost vydává, test na typ, počet a obsah vydaných událostí.

Mutation testing

Coverage říká, které řádky test spustil. Neříká, jestli by si všiml, kdyby se změnily. Na tuto otázku odpovídá mutation testing: nástroj zanese do kódu drobné změny (obrátí podmínku, posune mez, smaže volání) a spustí testy. Mutace, kterou nikdo nezachytil, ukazuje na řádek, který má pokrytí, ale nemá assert. Podíl zachycených mutací je mutation score.

V PHP mutace generuje Infection [18]. Nejvíc se vyplatí nad doménovou vrstvou: logika je tam hustá, testy rychlé a mutace mají co porušit. Nad infrastrukturou běh trvá dlouho a nálezy bývají technické.

◢ Vzor

Příklad: Spuštění Infection nad doménovou vrstvou

bash snippet.sh

1composer require --dev infection/infection2 3# Zdrojové adresáře se nastavují v infection.json5, práh se hlídá v CI4vendor/bin/infection --threads=max --min-msi=80

Konfigurace a spouštění

Čtyři testovací sady z předchozích sekcí definuje phpunit.dist.xml. PHPUnit hledá konfiguraci v pořadí phpunit.xml, phpunit.dist.xml, phpunit.xml.dist. Starší název tedy dál funguje, jen má nejnižší prioritu. Ve stejném souboru se registruje i extension pro transakční izolaci z sekce o integračních testech:

◢ Vzor

Příklad: phpunit.dist.xml se čtyřmi testsuitami

xml phpunit.dist.xml

1<?xml version="1.0" encoding="UTF-8"?>2<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"3         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"4         bootstrap="tests/bootstrap.php"5         cacheDirectory=".phpunit.cache"6         failOnWarning="true"7         failOnDeprecation="true"8>9    <php>10        <server name="APP_ENV" value="test" force="true"/>11        <server name="KERNEL_CLASS" value="App\Kernel"/>12        <!-- Bez ztlumení sypou funkční testy monolog do výstupu PHPUnitu -->13        <server name="SHELL_VERBOSITY" value="-1"/>14    </php>15 16    <!--17        Sady musí dohromady pokrýt celý adresář tests/. Co do žádné z nich18        nespadne, PHPUnit mlčky vynechá a CI zůstane zelené. Kontrolu udělá19        porovnání `vendor/bin/phpunit` a `vendor/bin/phpunit tests` -20        musí hlásit stejný počet testů.21    -->22    <testsuites>23        <!-- Doména běží bez kernelu - tuto sadu lze spouštět po každé změně -->24        <testsuite name="Domain">25            <directory>tests/*/Domain</directory>26        </testsuite>27        <testsuite name="Application">28            <directory>tests/*/Application</directory>29        </testsuite>30        <testsuite name="Integration">31            <directory>tests/*/Infrastructure</directory>32        </testsuite>33        <testsuite name="Functional">34            <directory>tests/*/Functional</directory>35            <!-- Feature slice si drží testy u sebe, ne pod Functional/ -->36            <directory>tests/*/*/Controller</directory>37        </testsuite>38    </testsuites>39 40    <source>41        <include>42            <directory>src</directory>43        </include>44    </source>45 46    <!-- Transakční izolace integračních a funkčních testů -->47    <extensions>48        <bootstrap class="DAMA\DoctrineTestBundle\PHPUnit\PHPUnitExtension"/>49    </extensions>50</phpunit>

Samotný zápis v <extensions> nestačí. Recept dama/doctrine-test-bundle leží v contrib repozitáři, takže ho Flex bez potvrzení (nebo bez extra.symfony.allow-contrib) nespustí a bundle nezaregistruje. Rozšíření pak sice nastartuje, ale nic nevrací zpět. Pozná se to podle toho, že testy projdou jednou a při druhém běhu spadnou na datech z toho prvního. Bundle proto patří do config/bundles.php:

php config/bundles.php

1<?php2 3return [4    // …5    DAMA\DoctrineTestBundle\DAMADoctrineTestBundle::class => ['test' => true],6];

◢ Vzor

Příklad: Spuštění testových sad pro DDD projekt

bash snippet.sh

1# Spuštění unit testů doménové vrstvy (rychlé, bez kernelu)2vendor/bin/phpunit --testsuite=Domain3 4# Spuštění integračních testů (vyžaduje databázi)5vendor/bin/phpunit --testsuite=Integration6 7# Spuštění funkčních testů8vendor/bin/phpunit --testsuite=Functional9 10# Generování HTML coverage reportu (vyžaduje Xdebug nebo PCOV)11XDEBUG_MODE=coverage vendor/bin/phpunit --coverage-html=coverage/12 13# Spuštění architektonických testů s Deptrac14vendor/bin/deptrac analyse

Testovací pyramida v DDD funguje díky tomu, že doménová vrstva je čisté PHP bez závislostí na frameworku. Doménová sada se proto dá spustit po každé změně, ne až v CI. Integrační a funkční testy doplňují pokrytí tam, kde vstupuje infrastruktura, a architektonické testy hlídají, aby izolace domény nezmizela při dalším refaktoringu.

Časté otázky

Jak testovat agregát – unit test s mock repozitářem, nebo integrační test?

Agregát se testuje primárně unit testem, protože je to čisté PHP bez závislostí na frameworku nebo databázi. Test vytvoří agregát, volá jeho metody a ověřuje výsledný stav i vyvolané doménové události. Mock repozitáře přitom není potřeba, protože samotný agregát repozitář nevolá. Integrační test doplňuje pokrytí až na úrovni, kde vstupuje persistence, tedy při ukládání a načítání agregátu. Podrobný rozbor v sekci Unit testy doménové vrstvy.

K čemu slouží InMemory repozitář a kdy ho preferovat před mockem?

InMemory repozitář je plnohodnotná implementace rozhraní repozitáře, která drží agregáty v poli v paměti. Oproti mocku simuluje reálné chování (najít, uložit, počítat), takže testy aplikačních služeb procházejí celý use case věrohodněji. Mock se hodí tam, kde jde o konkrétní interakci: kolikrát se metoda volala a s jakými argumenty. InMemory repozitář naopak slouží pro ověření výsledku, ne volání. Rozbor variant v sekci Test doubles a InMemory repozitáře.

Jak ověřit, že agregát publikuje správné doménové události?

Po vykonání metody se z agregátu vyčte seznam zaznamenaných událostí (typicky přes releaseEvents()) a testem se ověří jejich typ, pořadí i obsah. Kontroluje se, že agregát vyvolal přesně ty události, které má, a nevyvolal žádné navíc. Pro funkční test lze stejné události zachytávat přes Messenger event bus a ověřit reakce dalších částí systému. Praktický příklad v sekci Testování doménových událostí.

Mají se testovat privátní invarianty agregátu, nebo jen veřejné rozhraní?

Testuje se pouze veřejné rozhraní, tedy chování agregátu přes metody, které se reálně volají z aplikační vrstvy. Privátní invarianty jsou detailem implementace. Jejich přímé testování sváže test s konkrétní strukturou kódu a brání refaktoringu. Dobře navržený test ověřuje, že po sérii veřejných volání je agregát ve validním stavu, vyvolal očekávané události a při porušení pravidla vyhodil konkrétní doménovou výjimku. Detailní rozbor v sekci Unit testy doménové vrstvy.

Co jsou architektonické testy a co kontrolují?

Architektonické testy automaticky ověřují, že kód dodržuje zvolená pravidla struktury: například že doménová vrstva nezávisí na infrastruktuře, že agregáty nevolají repozitáře přímo, nebo že kontrolery nekomunikují s infrastrukturou. V PHP se k tomu běžně používá Deptrac (balíček deptrac/deptrac), který pravidla popisuje deklarativně v souboru deptrac.php a spouští se v CI jako samostatný krok vedle testovací sady. Porušení pravidla se projeví jako spadlý build, nikoli až při code review. Rozbor nástrojů a pravidel v sekci Architektonické testy.