Bird
Raised Fist0
Laravelframework~30 mins

Mocking and faking in Laravel - Mini Project: Build & Apply

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Mocking and Faking in Laravel Testing
📖 Scenario: You are building a Laravel application that sends welcome emails to new users. To ensure your email sending logic works correctly without actually sending emails during tests, you will use Laravel's mocking and faking features.
🎯 Goal: Build a simple Laravel test that fakes the mail sending and verifies that the welcome email is sent when a new user is created.
📋 What You'll Learn
Create a User model instance with specific attributes
Fake the mail sending using Laravel's Mail facade
Trigger the welcome email sending logic
Assert that the welcome email was sent to the correct user
💡 Why This Matters
🌍 Real World
In real Laravel applications, you want to test email sending without actually sending emails. Mocking and faking mail helps you verify your code works safely and quickly.
💼 Career
Understanding mocking and faking is essential for Laravel developers to write reliable automated tests, which is a key skill in professional software development.
Progress0 / 4 steps
1
Create a User instance
Create a variable called $user that holds a new User instance with the name set to 'John Doe' and email set to 'john@example.com'.
Laravel
Hint

Use new User([...]) to create the user instance with the exact attributes.

2
Fake the Mail facade
Add the line \Illuminate\Support\Facades\Mail::fake(); at the start of the test_welcome_email_is_sent method to fake mail sending.
Laravel
Hint

Use Mail::fake(); to prevent actual emails from being sent during the test.

3
Trigger the welcome email sending
Call the method sendWelcomeEmail() on the $user variable to simulate sending the welcome email.
Laravel
Hint

Call sendWelcomeEmail() on the $user variable to trigger the email logic.

4
Assert the welcome email was sent
Add an assertion using Mail::assertSent() to check that the App\Mail\WelcomeMail was sent to 'john@example.com'.
Laravel
Hint

Use Mail::assertSent(WelcomeMail::class, fn($mail) => $mail->hasTo('john@example.com')); to check the email was sent.

Practice

(1/5)
1. What is the main purpose of mocking and faking in Laravel testing?
easy
A. To automatically generate user interfaces
B. To simulate external services without performing real actions
C. To permanently store test data in the database
D. To speed up the application in production

Solution

  1. Step 1: Understand mocking and faking concept

    Mocking and faking are used to imitate external services or actions during tests without actually performing them.
  2. Step 2: Identify the purpose in Laravel testing

    Laravel uses mocking and faking to avoid real side effects like sending emails or making HTTP requests during tests.
  3. Final Answer:

    To simulate external services without performing real actions -> Option B
  4. Quick Check:

    Mocking = simulate services [OK]
Hint: Mocking means faking external actions in tests [OK]
Common Mistakes:
  • Thinking mocking speeds up production
  • Confusing mocking with real data storage
  • Assuming mocking creates UI automatically
2. Which Laravel method correctly fakes sending emails in a test?
easy
A. Mail::fake();
B. Mail::sendFake();
C. Mail::mock();
D. Mail::simulate();

Solution

  1. Step 1: Recall Laravel's mail faking method

    Laravel provides the Mail::fake() method to fake email sending during tests.
  2. Step 2: Check method correctness

    Only Mail::fake() is the correct and existing method; others are invalid or do not exist.
  3. Final Answer:

    Mail::fake(); -> Option A
  4. Quick Check:

    Mail::fake() = correct syntax [OK]
Hint: Use Mail::fake() to fake emails in Laravel tests [OK]
Common Mistakes:
  • Using non-existent methods like Mail::sendFake()
  • Confusing mock() with fake()
  • Forgetting the parentheses ()
3. What will the following Laravel test code output?
use Illuminate\Support\Facades\Http;

Http::fake();

$response = Http::get('https://example.com/api');

return $response->status();
medium
A. null
B. 404
C. 500
D. 200

Solution

  1. Step 1: Understand Http::fake() behavior

    Http::fake() fakes all HTTP requests and returns a default successful response with status 200.
  2. Step 2: Analyze the returned status code

    The $response->status() returns 200 because the fake response simulates success.
  3. Final Answer:

    200 -> Option D
  4. Quick Check:

    Http::fake() returns 200 status [OK]
Hint: Http::fake() returns 200 status by default [OK]
Common Mistakes:
  • Assuming fake returns 404 or error
  • Expecting null instead of response object
  • Confusing Http::fake() with real HTTP call
4. Identify the error in this Laravel test code snippet:
use Illuminate\Support\Facades\Storage;

Storage::fake('local');

Storage::put('file.txt', 'Hello');

$this->assertTrue(Storage::exists('file.txt'));
medium
A. Storage::fake() must be called with 'public' disk, not 'local'
B. Storage::exists() should be Storage::disk('local')->exists()
C. No error, the code is correct
D. Storage::put() cannot be used after Storage::fake()

Solution

  1. Step 1: Understand Storage::fake() usage

    Storage::fake('local') fakes the 'local' disk, which is Laravel's default disk.
  2. Step 2: Check method calls for disk specification

    Storage::put() and Storage::exists() use the default disk ('local'), so they interact with the faked disk correctly. The assertion passes.
  3. Final Answer:

    No error, the code is correct -> Option C
  4. Quick Check:

    Default disk = 'local' [OK]
Hint: Storage:: methods use default disk after Storage::fake('local') [OK]
Common Mistakes:
  • Thinking disk must always be explicitly specified
  • Believing Storage::put() is disallowed after fake
  • Confusing required disk names
5. You want to test that your Laravel app sends exactly one notification to a user without actually sending it. Which approach correctly achieves this?
hard
A. Use Notification::fake() and then assertNotificationSent()
B. Use Notification::send() and check the database for records
C. Use Notification::mock() and assertNothingSent()
D. Use Notification::fake() and then assertNothingSent()

Solution

  1. Step 1: Choose the correct faking method for notifications

    Notification::fake() prevents real notifications from sending and allows assertions.
  2. Step 2: Use the right assertion to check one notification sent

    assertNotificationSent() verifies that a notification was sent exactly once to the user.
  3. Final Answer:

    Use Notification::fake() and then assertNotificationSent() -> Option A
  4. Quick Check:

    Notification::fake() + assertNotificationSent() = test notifications [OK]
Hint: Fake notifications, then assertNotificationSent() to check sends [OK]
Common Mistakes:
  • Using assertNothingSent() when expecting a notification
  • Trying to check notifications via database records
  • Using non-existent Notification::mock() method