2026년 Laravel 테스트 완벽 가이드: Pest 4, 모킹, 아키텍처 테스트 및 면접 핵심 질문

PHP 생태계에서 테스트 전략의 성숙도는 애플리케이션의 안정성과 개발팀의 전문성을 직접적으로 반영합니다. Laravel 프레임워크는 출시 초기부터 테스트 친화적인 설계를 핵심 철학으로 삼아 왔으며, 2026년 현재 Pest가 Laravel 프로젝트의 사실상 표준 테스트 프레임워크로 자리 잡았습니다. Pest 4는 PHPUnit 위에 구축된 표현적 구문을 제공하면서도 아키텍처 테스트와 뮤테이션 테스트를 네이티브로 지원하여, 별도의 패키지 없이도 종합적인 테스트 전략을 수립할 수 있게 합니다.

기술 면접에서 Laravel 테스트 역량은 단순한 구문 암기가 아닌 테스트 설계 원칙에 대한 이해로 평가됩니다. 파사드 모킹과 Mockery의 차이점, 단위 테스트와 기능 테스트의 적절한 구분, 뮤테이션 테스트를 통한 테스트 품질 검증 등은 실무 경험을 갖춘 개발자와 이론만 아는 개발자를 구별하는 핵심 지표입니다.

이 글에서는 Pest 4의 설정부터 고급 모킹 패턴, 아키텍처 테스트, 뮤테이션 테스트까지 단계별로 해설하며, 각 주제에 해당하는 면접 질문과 실전 코드 예제를 제공합니다. 모든 코드는 Laravel 12 환경에서 즉시 적용 가능합니다.

Pest 4 설정과 프로젝트 구성

Pest의 설정은 tests/Pest.php 파일을 중심으로 이루어집니다. 이 파일은 모든 테스트 파일에 자동으로 적용되는 기본 클래스와 트레이트를 정의하여, 개별 테스트에서 반복적인 선언을 제거합니다.

use Illuminate\Foundation\Testing\RefreshDatabase;

pest()
    ->extend(Tests\TestCase::class)
    ->use(RefreshDatabase::class)
    ->in('Feature');

extend() 메서드는 Laravel의 TestCase 클래스를 모든 테스트에 연결하여 HTTP 메서드(getJson, postJson), 인증 시뮬레이션(actingAs), 응답 어설션에 대한 접근을 제공합니다. RefreshDatabase 트레이트는 각 테스트 사이에 데이터베이스 트랜잭션을 사용하여 상태를 초기화하므로, 마이그레이션을 매번 다시 실행하는 비용 없이 완전한 격리를 보장합니다.

->in('Feature') 지시문은 이 설정을 기능 테스트에만 적용합니다. tests/Unit/ 디렉터리의 단위 테스트는 데이터베이스 연결 없는 가벼운 환경에서 실행되므로, 실행 속도가 훨씬 빠릅니다. 이러한 분리는 테스트 피라미드 원칙을 반영하며, 면접에서 자주 평가되는 설계 판단입니다.

기능 테스트: HTTP 엔드포인트 검증

기능 테스트는 HTTP 요청부터 응답까지 전체 처리 과정을 검증합니다. Pest의 유창한 구문을 사용하면 상태 코드 검증, JSON 구조 확인, 데이터베이스 상태 검증을 하나의 테스트에서 자연스럽게 연결할 수 있습니다.

다음 테스트는 REST API를 통한 사용자 등록 프로세스를 검증합니다.

use App\Models\User;

it('registers a new user with valid data', function () {
    $response = $this->postJson('/api/register', [
        'name' => 'Jane Doe',
        'email' => 'jane@example.com',
        'password' => 'SecurePass123!',
        'password_confirmation' => 'SecurePass123!',
    ]);

    $response->assertStatus(201)
        ->assertJsonStructure(['user' => ['id', 'name', 'email']]);

    expect(User::where('email', 'jane@example.com')->exists())->toBeTrue();
});

postJson() 메서드는 JSON 헤더가 자동으로 설정된 POST 요청을 전송하여 실제 API 클라이언트를 시뮬레이션합니다. assertJsonStructure는 특정 값이 아닌 키의 존재 여부만 검증하므로, 응답의 사소한 변경에도 테스트가 깨지지 않는 탄력성을 확보합니다. 마지막 expect() 어설션은 사용자가 데이터베이스에 실제로 저장되었는지 확인하여, 요청 처리 체인 전체를 검증합니다.

이 접근 방식은 라우팅, 미들웨어, 데이터 유효성 검사, 컨트롤러 로직, 데이터 영속화를 한 번에 검증합니다. 어떤 계층에서든 문제가 발생하면 테스트가 실패하므로, 리팩터링 시 안전망 역할을 합니다.

단위 테스트: 격리된 비즈니스 로직 검증

단위 테스트는 데이터베이스, 파일 시스템, 외부 서비스와의 상호작용 없이 개별 클래스나 메서드를 대상으로 합니다. 밀리초 단위로 실행되며 테스트 피라미드의 가장 견고한 기반을 구성합니다.

use App\Services\PriceCalculator;

describe('PriceCalculator', function () {
    it('applies a percentage discount correctly', function () {
        $calculator = new PriceCalculator();
        $result = $calculator->applyDiscount(150.00, 20);
        expect($result)->toBe(120.00);
    });

    it('rejects negative discount values', function () {
        $calculator = new PriceCalculator();
        expect(fn () => $calculator->applyDiscount(100.00, -5))
            ->toThrow(InvalidArgumentException::class);
    });
});

describe 블록은 동일한 클래스나 기능에 대한 테스트를 논리적으로 그룹화하여, 실행 보고서의 가독성을 높입니다. toThrow() 어설션은 잘못된 입력에 대해 예외가 올바르게 발생하는지 확인하며, 이는 비즈니스 로직에서 필수적인 방어적 프로그래밍 패턴입니다.

면접에서는 단위 테스트 대상(계산 로직, 데이터 변환, 비즈니스 규칙 검증)과 기능 테스트 대상(HTTP 상호작용, 데이터베이스 통합)을 명확히 구분하는 능력이 기술적 성숙도의 핵심 지표로 평가됩니다.

파사드 모킹: Mail, Queue, Notification

Laravel의 파사드 시스템은 프레임워크 서비스에 대한 정적 인터페이스를 제공합니다. 테스트 환경에서는 fake() 메서드를 통해 실제 구현을 테스트 더블로 교체하여, 이메일 전송이나 잡 디스패치와 같은 부수 효과 없이 동작을 검증할 수 있습니다.

use App\Models\Order;
use App\Models\User;
use Illuminate\Support\Facades\Mail;
use Illuminate\Support\Facades\Queue;
use App\Mail\OrderConfirmation;
use App\Jobs\ProcessPayment;

it('dispatches payment job and sends confirmation email', function () {
    Mail::fake();
    Queue::fake();

    $user = User::factory()->create();
    $order = Order::factory()->for($user)->create([
        'total' => 99.99,
        'status' => 'pending',
    ]);

    $this->actingAs($user)
        ->postJson("/api/orders/{$order->id}/confirm")
        ->assertOk();

    Queue::assertPushed(ProcessPayment::class, function ($job) use ($order) {
        return $job->order->id === $order->id
            && $job->order->total === 99.99;
    });

    Mail::assertSent(OrderConfirmation::class, function ($mail) use ($user) {
        return $mail->hasTo($user->email);
    });
});

Mail::fake()와 Queue::fake()는 테스트 기간 동안 각각 이메일 전송과 잡 디스패치를 가로챕니다. 실제 이메일이 발송되거나 잡이 백그라운드에서 실행되지 않습니다. assertPushed와 assertSent 어설션은 올바른 클래스가 올바른 매개변수와 함께 디스패치되었는지 검증합니다.

Queue::assertPushed에 전달된 클로저는 고급 패턴을 보여줍니다. 잡이 디스패치되었다는 사실뿐만 아니라 잡의 프로퍼티에 올바른 값이 포함되어 있는지까지 확인합니다. 이 수준의 어설션 세분화는 리팩터링 과정에서 잘못된 객체가 잡에 전달되는 미묘한 버그를 감지합니다.

Mockery를 활용한 외부 서비스 모킹

Laravel 파사드가 아닌 서드파티 서비스(Stripe, Twilio, 외부 API 클라이언트 등)에는 Mockery를 사용하여 세밀한 제어가 가능한 테스트 더블을 생성합니다.

use App\Services\PaymentGateway;
use App\Services\StripeClient;

it('charges the customer through the payment gateway', function () {
    $stripeClient = Mockery::mock(StripeClient::class);
    $stripeClient->shouldReceive('charge')
        ->once()
        ->with('cus_abc123', 5000, 'usd')
        ->andReturn(['status' => 'succeeded', 'id' => 'ch_xyz']);

    $this->app->instance(StripeClient::class, $stripeClient);

    $gateway = app(PaymentGateway::class);
    $result = $gateway->processCharge('cus_abc123', 50.00);

    expect($result['status'])->toBe('succeeded');
});

Mockery::mock()는 메서드 호출을 가로채는 테스트 더블을 생성합니다. shouldReceive()->once()->with()->andReturn() 체이닝은 엄격한 계약을 정의합니다. charge 메서드가 지정된 매개변수로 정확히 한 번 호출되어야 하며, 정의된 값을 반환해야 합니다. 계약을 벗어나는 호출은 테스트 실패를 유발합니다.

$this->app->instance()는 모킹된 객체를 Laravel 서비스 컨테이너에 등록합니다. PaymentGateway가 의존성 주입을 통해 StripeClient 인스턴스를 요청하면, 컨테이너는 실제 구현 대신 모킹된 객체를 제공합니다. 이 메커니즘은 의존성 역전 원칙(DIP)에 기반하며, Laravel 애플리케이션의 테스트 용이성을 지탱하는 핵심 설계입니다.

processCharge에 전달되는 금액(50.00달러)과 charge에 전달되는 금액(5000센트)의 차이에 주목할 필요가 있습니다. 테스트는 PaymentGateway 내부의 변환 로직을 암묵적으로 검증하여, 금액 계산의 회귀를 감지합니다.

아키텍처 테스트: 프로젝트 규칙의 자동 적용

Pest는 PHP 생태계에서 독보적인 기능인 아키텍처 테스트를 제공합니다. 이 테스트는 애플리케이션 로직을 실행하지 않고 코드의 구조적 규칙 준수 여부를 정적으로 분석합니다. 팀이 합의한 아키텍처 결정을 자동화된 검증으로 보장합니다.

arch('controllers do not use Eloquent directly')
    ->expect('App\Http\Controllers')
    ->not->toUse('Illuminate\Database\Eloquent');

arch('services are final classes')
    ->expect('App\Services')
    ->toBeFinal();

arch('no debugging functions in production code')
    ->expect(['dd', 'dump', 'var_dump', 'ray'])
    ->not->toBeUsed();

첫 번째 테스트는 엄격한 아키텍처 분리를 강제합니다. 컨트롤러가 Eloquent를 직접 사용할 수 없도록 하여, 서비스 계층이나 리포지토리 패턴의 사용을 의무화합니다. 이 제약은 컨트롤러에 비즈니스 로직이 누적되는 안티패턴을 방지합니다.

두 번째 테스트는 서비스 클래스가 final로 선언되어야 함을 보장하여, 무분별한 상속으로 인한 유지보수 복잡성을 차단합니다. 세 번째 테스트는 프로덕션 코드에서 디버깅 함수가 누락된 채 남아 있는 문제를 감지하여 정보 유출을 방지합니다.

Pest는 Laravel 프로젝트에 맞춤화된 사전 구성 프리셋도 제공합니다.

arch()->preset()->laravel();
arch()->preset()->security();
arch()->preset()->php();

laravel() 프리셋은 컨트롤러가 올바른 기본 클래스를 상속하는지, 모델이 적절한 네임스페이스에 위치하는지, 네이밍 컨벤션이 준수되는지 확인합니다. security() 프리셋은 eval(), exec(), shell_exec()과 같은 위험한 함수의 사용을 감지합니다. php() 프리셋은 PHP 언어 수준의 모범 사례를 강제합니다.

면접에서 아키텍처 테스트에 대한 지식은 소프트웨어 품질에 대한 거시적 관점을 갖춘 개발자와 기능 테스트에만 집중하는 개발자를 구별합니다. 이 테스트는 팀의 아키텍처 결정을 CI 파이프라인에서 자동으로 실행 가능한 규칙으로 변환합니다.

뮤테이션 테스트: 테스트의 진짜 품질 측정

코드 커버리지는 테스트 실행 시 어떤 코드 라인이 실행되었는지를 측정하지만, 어설션의 정확도에 대해서는 아무것도 알려주지 않습니다. 뮤테이션 테스트는 소스 코드를 체계적으로 변형(연산자 교체, 조건 삭제, 반환값 변경)하고, 기존 테스트가 각 변형을 감지하는지 확인하여 이 격차를 해소합니다.

Pest는 뮤테이션 테스트를 네이티브로 지원하므로, 추가 설정 없이 바로 사용할 수 있습니다.

php artisan test --mutate --class=App\\Services\\PriceCalculator

이 명령은 대상 클래스를 분석하여 뮤턴트를 생성하고, 각 뮤턴트에 대해 테스트 스위트를 실행합니다. 보고서에는 기존 테스트가 감지한 뮤턴트의 비율인 뮤테이션 스코어가 표시됩니다.

다음 예제는 높은 커버리지를 가지지만 낮은 뮤테이션 스코어를 보이는 테스트와 견고한 테스트의 차이를 보여줍니다.

it('calculates shipping cost', function () {
    $cost = calculateShipping(weight: 5.0, zone: 'domestic');
    expect($cost)->toBeFloat();
});

it('calculates domestic shipping for 5kg package', function () {
    $cost = calculateShipping(weight: 5.0, zone: 'domestic');
    expect($cost)->toBe(12.50);
});

첫 번째 테스트는 계산 공식이 완전히 변경되어도 통과합니다. 어떤 부동소수점 숫자든 toBeFloat() 어설션을 만족시키기 때문입니다. 두 번째 테스트는 정확한 기대값을 지정하여, 계산 로직의 어떤 변형이든 감지합니다. 광범위한 어설션과 정밀한 어설션의 차이는 면접에서 반복적으로 평가되는 핵심 개념입니다.

뮤테이션 스코어 90% 이상은 테스트 스위트가 미묘한 회귀를 감지할 수 있을 만큼 충분히 정밀하다는 것을 의미합니다. 이는 라인 커버리지 100%가 놓칠 수 있는 문제를 발견하는 데 효과적입니다.

데이터베이스 테스트와 팩토리 활용

Laravel 팩토리는 일관된 기본값으로 테스트 객체를 생성하는 메커니즘을 캡슐화합니다. 팩토리를 사용하면 테스트에서 관련 있는 속성만 명시적으로 지정하여 테스트의 의도를 명확하게 드러낼 수 있습니다.

use App\Models\Article;
use App\Models\User;

it('publishes a draft article and updates the timestamp', function () {
    $author = User::factory()->create(['role' => 'editor']);

    $article = Article::factory()
        ->for($author, 'author')
        ->draft()
        ->create(['title' => 'Testing Best Practices']);

    $this->actingAs($author)
        ->patchJson("/api/articles/{$article->id}/publish")
        ->assertOk()
        ->assertJsonPath('data.status', 'published');

    $article->refresh();

    expect($article->status)->toBe('published')
        ->and($article->published_at)->not->toBeNull()
        ->and($article->published_at->isToday())->toBeTrue();
});

이 테스트는 게시 워크플로우 전체를 검증합니다. draft() 팩토리 상태는 초안 상태의 기사를 생성하여 초기 컨텍스트를 시뮬레이션합니다. assertJsonPath는 전체 JSON 구조를 강제하지 않고 특정 경로의 값만 확인합니다. refresh()는 데이터베이스에서 모델을 다시 로드하여, 어설션이 로컬 캐시가 아닌 실제 영속화된 상태를 기준으로 수행되도록 보장합니다.

Pest의 ->and() 체이닝은 여러 프로퍼티를 하나의 유창한 표현식에서 검증할 수 있게 하여 테스트 가독성을 높입니다. isToday() 검증은 Laravel에 통합된 Carbon의 날짜 비교 기능을 활용하여, 게시 타임스탬프가 당일인지 확인합니다.

HTTP 응답 테스트: 인증과 유효성 검사

API 테스트에서 인증 흐름과 유효성 검사 에러 처리는 가장 빈번하게 검증되는 영역입니다. 다음 테스트 그룹은 인증 API의 세 가지 핵심 시나리오를 다룹니다.

use App\Models\User;

describe('API Authentication', function () {
    it('rejects unauthenticated requests with 401', function () {
        $this->getJson('/api/profile')
            ->assertUnauthorized();
    });

    it('returns the authenticated user profile', function () {
        $user = User::factory()->create([
            'name' => 'John Doe',
            'email' => 'john@example.com',
        ]);

        $this->actingAs($user)
            ->getJson('/api/profile')
            ->assertOk()
            ->assertJson([
                'data' => [
                    'name' => 'John Doe',
                    'email' => 'john@example.com',
                ],
            ]);
    });

    it('validates required fields on registration', function () {
        $this->postJson('/api/register', [])
            ->assertUnprocessable()
            ->assertJsonValidationErrors(['name', 'email', 'password']);
    });
});

이 테스트 그룹은 인증 기반 API의 세 가지 기본 시나리오를 포괄합니다. 비인증 요청의 거부(401), 인증된 사용자에 대한 올바른 응답, 필수 필드 유효성 검사 에러(422)입니다. assertUnauthorized()는 401 상태 코드를, assertUnprocessable()은 422 상태 코드를 각각 검증합니다.

assertJsonValidationErrors는 유효성 검사 에러가 올바르게 포맷되어 해당 필드와 연결되어 있는지 확인합니다. 이 패턴은 프론트엔드에서 각 폼 필드 아래에 에러 메시지를 표시하는 API에서 필수적입니다.

기술 면접에서 자주 출제되는 Laravel 테스트 질문

Laravel 테스트 관련 면접 질문은 구문 암기가 아닌 기저 메커니즘에 대한 이해도를 평가합니다. 2026년 현재 가장 빈번하게 출제되는 질문과 핵심 답변을 정리합니다.

fake(), mock(), spy()의 차이점은 무엇입니까?

fake()은 Laravel 파사드에 내장된 메서드로, 실제 서비스를 테스트 더블로 교체하여 부수 효과를 제거합니다(Mail::fake(), Queue::fake()). mock()은 Mockery를 통해 생성되며, 메서드 호출에 대한 기대(expectation)를 설정하여 호출 횟수와 매개변수를 엄격하게 검증합니다. spy()는 모킹과 유사하지만 모든 메서드 호출을 허용한 뒤 사후에 검증합니다. 파사드의 경우 fake()를 우선 사용하고, 파사드가 아닌 외부 서비스에는 mock()을, 호출 순서에 민감하지 않은 검증에는 spy()를 사용합니다.

RefreshDatabase와 DatabaseTransactions의 차이점은 무엇입니까?

RefreshDatabase는 첫 번째 테스트 실행 시 마이그레이션을 수행한 후, 각 테스트를 데이터베이스 트랜잭션으로 감싸서 테스트 종료 시 롤백합니다. 이 방식이 가장 빠르며 대부분의 경우에 적합합니다. DatabaseTransactions는 마이그레이션 실행 없이 트랜잭션만 사용합니다. 여러 데이터베이스 연결을 사용하는 테스트처럼 트랜잭션이 충분하지 않은 경우에는 DatabaseMigrations가 필요하며, 이 경우 매 테스트마다 전체 마이그레이션을 재실행합니다.

기능 테스트와 단위 테스트를 언제 사용해야 합니까?

단위 테스트는 외부 의존성 없이 순수 비즈니스 로직을 검증할 때 사용합니다. 가격 계산, 데이터 변환, 유효성 검사 규칙 등이 해당됩니다. 기능 테스트는 HTTP 요청-응답 사이클, 데이터베이스 상호작용, 미들웨어 동작 등 여러 계층이 통합된 동작을 검증할 때 사용합니다. 테스트 피라미드 원칙에 따라 단위 테스트를 가장 많이, 기능 테스트를 적절히, 통합 테스트를 가장 적게 작성하는 것이 효율적입니다.

뮤테이션 테스트가 코드 커버리지를 넘어서는 이유는 무엇입니까?

코드 커버리지는 실행된 코드 라인의 비율만 측정하며, 어설션이 실제로 올바른 동작을 검증하는지는 확인하지 않습니다. 뮤테이션 테스트는 소스 코드를 변형하여 테스트가 변형을 감지하는지 확인합니다. 커버리지 100%라도 어설션이 toBeFloat()처럼 광범위하면 뮤테이션 스코어가 낮을 수 있습니다. 뮤테이션 테스트는 테스트의 정밀도를 측정하는 메타 테스트로, 테스트 자체의 품질을 평가합니다.

아키텍처 테스트가 기존 테스트로 검증할 수 없는 것은 무엇입니까?

아키텍처 테스트는 코드를 실행하지 않고 구조와 의존성을 정적으로 분석합니다. 컨트롤러가 Eloquent를 직접 사용하거나, 디버깅 함수가 프로덕션 코드에 남아 있거나, 서비스 클래스가 final로 선언되지 않은 경우 등은 기능적으로는 정상 작동하지만 아키텍처적으로 위반인 상황입니다. 기능 테스트는 이러한 구조적 위반을 감지할 수 없습니다.

팩토리를 수동 삽입 대신 사용해야 하는 이유는 무엇입니까?

팩토리는 일관된 기본값으로 테스트 객체를 생성하고, 테스트에 관련된 속성만 명시적으로 지정할 수 있게 합니다. for()와 has() 메서드를 통해 모델 간 관계를 자동으로 관리하므로, 반복적인 데이터 생성 코드를 제거합니다. 이는 테스트의 의도를 명확히 드러내면서 유지보수 비용을 줄입니다.

더 많은 Laravel 면접 질문 모음에서 추가적인 출제 경향을 확인할 수 있으며, 서비스 컨테이너 패턴에 대한 심화 해설도 면접 준비에 유용합니다.

결론

2026년 Laravel 테스트 전략은 Pest 4를 중심으로 표현적 구문, 아키텍처 검증, 뮤테이션 테스트를 통합한 종합적 접근을 요구합니다. 기술 면접에서 이러한 테스트 역량의 입증은 코드 품질에 대한 전문성을 보여주는 가장 직접적인 방법입니다.

핵심 사항을 정리합니다.

• tests/Pest.php 설정 파일이 기본 클래스와 트레이트를 중앙 관리하여, 단위 테스트와 기능 테스트의 환경을 명확히 분리합니다
• 기능 테스트에서 postJson / assertStatus / expect 조합은 HTTP 요청 처리 체인 전체를 한 번에 검증합니다
• Mail::fake(), Queue::fake() 파사드 모킹은 비동기 처리를 테스트하는 표준 패턴이며, 서드파티 서비스에는 Mockery를 사용합니다
• 아키텍처 테스트는 팀의 구조적 규칙을 CI 파이프라인에서 자동으로 강제하여, 코드 리뷰의 부담을 줄입니다
• 뮤테이션 테스트의 스코어는 코드 커버리지가 측정하지 못하는 어설션의 정밀도를 드러냅니다
• 팩토리와 정밀한 JSON 어설션의 조합은 유지보수 가능한 테스트 작성의 기반입니다

Laravel 면접 준비를 체계적으로 진행하면, 테스트 관련 질문뿐 아니라 프레임워크 전반에 대한 실무적 이해를 면접관에게 효과적으로 전달할 수 있습니다.