Тестирование с PHPUnit — бесплатный тест онлайн

Вопрос 1 из 30

Что делает хороший unit-тест?

final class AccountTest extends TestCase
{
    public function testRejectsWithdrawalAboveBalance(): void
    {
        $account = Account::withBalance(100);
        $this->expectException(InsufficientFunds::class);
        $account->withdraw(101);
    }
}

Проверяет одно наблюдаемое поведение с управляемыми зависимостями Запускает реальные сеть, очередь и базу даже для чистого предметного правила Фиксирует вызовы каждого private-метода, не проверяя внешний контракт Сравнивает полный var_dump объекта вместо наблюдаемого результата Проверяет сразу несколько несвязанных сценариев, чтобы сократить число методов

Вопрос 2 из 30

Почему имя testItWorks слабое?

final class ServiceTest extends TestCase
{
    public function testItWorks(): void
    {
        self::assertFalse($this->service->run($this->input));
    }
}

works — зарезервированное слово Не сообщает условие и ожидаемый результат при падении PHPUnit запрещает английские имена Тест не запустится Имя слишком короткое для автозагрузки

Вопрос 3 из 30

Как проверить исключение?

$this->expectException(InvalidArgumentException::class);
$this->expectExceptionMessage('Количество должно быть положительным');
$order->addItem($product, 0);

Вызвать expectException до действия Обернуть всё в пустой catch Использовать @ Сравнить return с Exception Проверить error_log вручную

Вопрос 4 из 30

Что не так с тестом, который читает DateTimeImmutable("now")?

PHPUnit не поддерживает даты без установленного расширения intl Любое использование DateTimeImmutable делает тест интеграционным Объекты DateTimeImmutable нельзя сравнивать в PHPUnit Строка now всегда преобразуется в null в тестовом процессе Он зависит от реальных часов и может падать на границе

Вопрос 5 из 30

Почему тест private-метода через Reflection хрупок?

PHPUnit удаляет private-методы после создания тестового двойника Он привязан к внутренней декомпозиции, а не к контракту Такой тест полезнее внешнего: он точнее закрепляет текущую структуру реализации Основной риск только в скорости Reflection, контракт теста остаётся устойчивым Private-метод невозможно вызвать Reflection, поэтому тест всегда падает

Вопрос 6 из 30

Когда provider полезен?

final class QuantityTest extends TestCase
{
    /** @dataProvider invalidQuantities */
    public function testRejectsInvalidQuantity(int $quantity): void
    {
        $this->expectException(InvalidArgumentException::class);
        new Quantity($quantity);
    }
}

Только для строковых аргументов без объектов и ожидаемых исключений Когда каждый набор требует отдельной инфраструктуры и проверяет иной контракт Для запуска реального внешнего API на этапе обнаружения тестов Когда один контракт проверяется на ряде компактных входов и ожиданий Чтобы скрыть несколько больших сценариев в одном трудно читаемом методе

Вопрос 7 из 30

Зачем именовать datasets?

final class QuantityTest extends TestCase
{
    public static function invalidQuantities(): iterable
    {
        yield 'zero' => [0];
        yield 'negative' => [-1];
        yield 'too large' => [10_001];
    }
}

Имена меняют порядок выполнения наборов и тем самым ускоряют тест Без строковых ключей provider не будет обнаружен PHPUnit Ключ набора автоматически передаётся дополнительным параметром тестового метода В отчёте видно, какой сценарий упал, а не только индекс #3 Название шифрует входные данные и не отображается в отчёте

Вопрос 8 из 30

Что должен выдавать provider?

final class TotalTest extends TestCase
{
    public static function totals(): iterable
    {
        yield [100, 0, 100];
        yield [100, 10, 90];
    }
}

Наборы аргументов для тестового метода Логический признак, определяющий, запускать ли весь класс тестов PDOStatement, из которого тестовый метод сам читает аргументы Один готовый TestResult, который PHPUnit добавляет к отчёту без запуска метода HTML-фрагмент с описанием каждого набора и ожидаемого результата

Вопрос 9 из 30

Почему network-call внутри provider плох?

Проблема только в скорости; доступность сервиса и побочные эффекты не влияют Любая сеть в provider автоматически подменяется PHPUnit стабильным ответом Он запускается при обнаружении и делает тест нестабильным Provider не имеет права вызывать функции, даже чистые и локальные Сетевой вызов выполняется только после assert и не влияет на обнаружение

Вопрос 10 из 30

Какие случаи нужны для диапазона 1..10?

0 и 11: достаточно проверить два отклонённых значения Только 1 и 10: проверка допустимых границ полностью покрывает диапазон Сто случайных чисел от 1 до 10 без фиксированных граничных случаев 0, 1, типичное, 10 и 11 1, 5 и 10: внешние значения не нужны, если тип параметра int

Вопрос 11 из 30

Чем stub отличается от mock в практическом смысле?

$clock = $this->createStub(Clock::class);
$clock->method('now')->willReturn(new DateTimeImmutable('2026-07-14'));

$mailer = $this->createMock(Mailer::class);
$mailer->expects(self::once())->method('send');

Stub даёт ответы, mock ещё проверяет взаимодействия Mock может проверять взаимодействие, но не способен возвращать заданное значение Stub обязан использовать реальную базу, а mock всегда работает в памяти Практического различия нет: оба термина обозначают любой заменённый объект Stub проверяет число вызовов, а mock служит только источником данных

Вопрос 12 из 30

Когда fake удобнее сложного mock?

$repository = new InMemoryUserRepository();
$repository->save($user);
self::assertSame($user, $repository->get($user->id()));

Для рабочего платёжного шлюза, чтобы unit-тесты выполняли настоящие операции Только для final-классов, которые нельзя создать обычным конструктором Когда поведение проще описать десятками ожиданий, чем небольшой реализацией в памяти Когда нужно скрыть ошибки взаимодействия и всегда возвращать успех Когда рабочая реализация в памяти яснее множества ожиданий

Вопрос 13 из 30

Почему не стоит мокировать value object Money?

$price = new Money(1000, 'RUB');
$discount = new Money(100, 'RUB');
self::assertEquals(new Money(900, 'RUB'), $price->minus($discount));

Money хранит SQL-соединение, поэтому его нельзя создавать в unit-тесте Value object следует проверять только косвенно через контроллер Реальный Money прост, детерминирован и надёжнее mock Тестовые двойники не поддерживают числа и арифметические операции Класс final автоматически делает любой mock точнее реального объекта

Вопрос 14 из 30

Что проверить у Mailer mock?

Точный экземпляр PDO, которым письмо было записано в журнал Каждый внутренний вызов mailer, включая построение транспорта и заголовков Отправлено одно сообщение нужному получателю Порядок всех локальных переменных внутри метода отправки Количество строк исходного класса после вызова send

Вопрос 15 из 30

Почему mock, возвращающий невозможные данные, вреден?

Такой mock только ускоряет тест и не влияет на смысл сценария PHPUnit автоматически исправит значение до допустимого перед передачей коду Тестовый двойник обязан возвращать null при любой неопределённости Невозможные ответы полезны: они расширяют покрытие за пределы контракта Тест подтверждает невозможный сценарий зависимости

Вопрос 16 из 30

Что проверяет интеграционный тест репозитория?

$repository = new PdoUserRepository($this->database);
$repository->save(new User(1, 'a@example.test'));
self::assertSame('a@example.test', $repository->get(1)->email);

Только объявленный интерфейс репозитория без запуска реализации Сериализацию HTTP-ответа, CSS и маршрутизацию контроллера Имя файла миграции и расположение SQL в каталоге проекта SQL, отображение, ограничения и транзакции СУБД Private-методы PDO, вызванные конкретной версией драйвера

Вопрос 17 из 30

Как изолировать тесты базы?

final class RepositoryTest extends TestCase
{
    protected function setUp(): void
    {
        $this->pdo->beginTransaction();
    }

    protected function tearDown(): void
    {
        if ($this->pdo->inTransaction()) {
            $this->pdo->rollBack();
        }
    }
}

Не очищать данные, если имена тестовых сущностей достаточно уникальны Удалять случайные строки рабочей базы после каждого тестового метода Одна общая база с остатками предыдущих тестов и фиксированным порядком запуска Чистая схема или транзакция на тест и гарантированная очистка Полагаться на порядок методов, чтобы каждый подготавливал данные следующему

Вопрос 18 из 30

Почему SQLite может быть недостаточна?

$pdo = new PDO('sqlite::memory:');
$pdo->exec('CREATE TABLE events (payload TEXT NOT NULL)');

$repository = new EventRepository($pdo);

SQLite всегда медленнее целевой серверной СУБД и потому строже SQLite не поддерживает таблицы, индексы и транзакции Различия ограничиваются синтаксисом LIMIT и не затрагивают поведение Отличаются диалект, типы, блокировки и ограничения PDO не умеет работать с SQLite в памяти из PHPUnit

Вопрос 19 из 30

Что проверять у миграции?

Только применение down на пустой схеме без данных и зависимых объектов Отображение административной страницы после ручного применения миграции Применение на чистой и существующей схеме Имя файла и порядковый номер: содержимое миграции проверяет фреймворк Длину SQL и число операторов без выполнения на реальной схеме

Вопрос 20 из 30

Когда HTTP-тест полезен?

Вместо всех нижележащих тестов: HTTP-путь полностью заменяет их Для каждой арифметической функции вместо быстрого unit-теста Только для вызовов внешнего Google API, а маршруты приложения не требуют такого теста Для маршрутизации, сериализации, auth и middleware приложения Чтобы проверить private-свойства контроллера через сериализованный Response

Вопрос 21 из 30

Что такое flaky-тест?

final class OfferTest extends TestCase
{
    public function testExpiresAtNoon(): void
    {
        $offer = new Offer(expiresAt: new DateTimeImmutable('today 12:00'));
        self::assertTrue($offer->isActive(new DateTimeImmutable('now')));
    }
}

Любой тест без отдельного assert, даже если он ожидает исключение Любой медленный интеграционный тест независимо от стабильности результата Тест private-метода, который ломается только после рефакторинга структуры Тест, который без изменений то проходит, то падает Тест с data provider, который выполняется несколько раз с разными данными

Вопрос 22 из 30

Как локализовать зависимость от порядка?

$tests = ['creates user', 'updates user', 'deletes user'];
shuffle($tests);
foreach ($tests as $test) {
    runTestInIsolatedState($test);
}

Зафиксировать один порядок в конфигурации и больше не запускать тест отдельно Удалить падающее утверждение, чтобы общее состояние не проявлялось Добавить sleep между методами вместо очистки базы, времени и статических данных Запускать отдельно и случайно, проверяя очистку состояния Перезапускать рабочое окружение, пока набор не пройдёт полностью

Вопрос 23 из 30

Что показывает coverage?

$result = $coverage->summary();
printf('Lines: %.1f%%, branches: %.1f%%', $result->lines, $result->branches);

Что все возможные ошибки найдены, даже если ветви не были проверены по результату Что приложение не упадёт в production при любом входе и отказе зависимости Что каждая исполненная строка содержит достаточно сильное утверждение Что все требования реализованы корректно и все проверки имеют смысл Исполненные строки и ветви, но не качество проверок

Вопрос 24 из 30

Зачем фиксировать seed случайного теста?

PHPUnit требует единственный seed для всего проекта и не примет другой Seed делает числа навсегда одинаковыми и превращает property-test в обычный пример Чтобы точно воспроизвести упавший набор данных Фиксация seed скрывает ошибку, поскольку повтор больше не считается случайным Главная цель seed — ускорить SQL-запросы в тестовой базе

Вопрос 25 из 30

Как улучшить сообщение assert?

Вывести полный дамп базы и окружения при любом несовпадении Показать предметное различие и важный контекст Добавить секреты и токены, чтобы разработчик мог повторить запрос вручную Ограничиться значением false без названия правила и важных входных данных Удалить expected и actual, оставив только общий текст «тест не прошёл»

Вопрос 26 из 30

Какой тест обязателен для защищённого ресурса?

$response = $client->as($alice)->get('/orders/' . $bobOrder->id);
self::assertSame(404, $response->status());

Только 404 для несуществующего маршрута, не проверяя чужой ресурс Только отсутствие cookie у неавторизованного запроса Длину идентификатора объекта как косвенный признак невозможности подбора Пользователь не может читать или менять чужой объект Только успешный доступ владельца: отрицательный сценарий следует из него

Вопрос 27 из 30

Что делать с секретами в fixtures?

$fixture = [
    'api_key' => 'test_key_not_valid_anywhere',
    'password' => 'example-only',
];
$scanner->assertNoRealSecrets($repositoryPath);

Хранить реальный токен в base64: это достаточно скрывает значение Фиктивные значения и автоматическое сканирование репозитория Копировать рабочий .env, чтобы fixtures точно совпадали с production Отправлять набор fixtures во внешний сервис для проверки валидности ключей Печатать секрет в отчёте при падении, чтобы упростить диагностику

Вопрос 28 из 30

Как тестировать внешний платёжный сервис?

$gateway = new FakePaymentGateway();
$service = new Checkout($gateway);
$service->pay($order);
self::assertSame($order->total(), $gateway->lastAmount());

Unit-тест порта и отдельные контрактные тесты адаптера Ограничиться mock порта и никогда не проверять реальный HTTP-адаптер Использовать рабочую карту и production endpoint в непрерывной проверке Проверять только успешный ответ, не моделируя timeout, отказ и повтор Всегда выполнять настоящий платёж в каждом unit-тесте сценария

Вопрос 29 из 30

Какой quality gate разумен?

Запрет любых предупреждений без оценки их класса, причины и допустимого порога Автоматический выпуск после прохождения одного unit-теста нового метода Требование 100% coverage как единственный критерий качества изменений Только ручной клик по одному успешному сценарию перед выпуском Тесты, статанализ, audit и отсутствие критичных регрессий

Вопрос 30 из 30

Почему тесты должны запускаться из чистой установки lock-файла?

Иначе локальный vendor скрывает отсутствующие зависимости Чистая установка изменяет исходный PHP-код и потому не годится для проверки Локальный vendor всегда полностью совпадает с lock-файлом после любого update Тесты используют собственный autoload и не зависят от vendor composer.lock не влияет на набор установленных версий при composer install