0x55aa
← Back to Blog

Laravel Testing That Won't Make You Cry 🧪

•7 min read
laravelphptestingweb-devtdd

Laravel Testing That Won't Make You Cry 🧪

Remember that time you deployed on Friday, broke production, and spent the weekend fixing it? Yeah, me too. Let's make sure that NEVER happens again!

Testing gets a bad rap because most tutorials make it look like homework. But here's the truth: good tests are like having a safety net while walking a tightrope. They're not just nice to have - they're your insurance policy against 3 AM panic attacks!

Why You Should Actually Care About Testing 🎯

Real talk: I used to skip tests too. "I'll just be careful," I'd say. Then one "tiny change" broke the entire checkout flow and cost my client actual money. Not fun!

The wake-up call: Tests aren't about being a perfectionist. They're about:

  • Deploying with confidence (not crossed fingers)
  • Catching bugs BEFORE users do
  • Refactoring without fear
  • Sleeping peacefully on Friday nights 😴

1. Feature Tests: Test Like a User Would 👤

Feature tests are your bread and butter. They simulate actual user interactions - clicking buttons, filling forms, navigating pages.

The scenario: Testing a blog post creation flow

public function test_user_can_create_a_post()
{
    // Arrange: Set up what you need
    $user = User::factory()->create();

    // Act: Do the thing
    $response = $this->actingAs($user)->post('/posts', [
        'title' => 'My Awesome Post',
        'content' => 'This is some great content!'
    ]);

    // Assert: Check it worked
    $response->assertRedirect('/posts');
    $this->assertDatabaseHas('posts', [
        'title' => 'My Awesome Post',
        'user_id' => $user->id
    ]);
}

The magic: This test checks EVERYTHING - routing, validation, database insertion, and redirect. If any part breaks, you'll know!

Pro tip: Follow the AAA pattern (Arrange, Act, Assert). It keeps your tests readable and your brain happy!

2. Test Your Auth Like Your Job Depends on It 🔐

Because, well... it might!

public function test_guests_cannot_create_posts()
{
    // Try to create a post without logging in
    $response = $this->post('/posts', [
        'title' => 'Sneaky Post',
        'content' => 'Trying to hack the system!'
    ]);

    // Should get kicked to login
    $response->assertRedirect('/login');

    // Nothing should be created
    $this->assertDatabaseCount('posts', 0);
}

public function test_users_cannot_delete_others_posts()
{
    $john = User::factory()->create();
    $jane = User::factory()->create();
    $johnsPost = Post::factory()->create(['user_id' => $john->id]);

    // Jane tries to delete John's post
    $response = $this->actingAs($jane)
        ->delete("/posts/{$johnsPost->id}");

    $response->assertForbidden(); // Nope!
    $this->assertDatabaseHas('posts', ['id' => $johnsPost->id]);
}

Why this matters: Security bugs are the worst. These tests make sure only authorized users can do authorized things!

3. Factories Are Your Best Friend 🏭

Bad way: Creating test data manually every time

// Ugh, so much typing...
$user = User::create([
    'name' => 'Test User',
    'email' => '[email protected]',
    'password' => Hash::make('password'),
    'email_verified_at' => now(),
    // ... 10 more fields
]);

Good way: Use factories!

// One line. Beautiful! 😍
$user = User::factory()->create();

// Need 10 users? Easy!
$users = User::factory(10)->create();

// Need a specific state?
$admin = User::factory()->admin()->create();
$unverified = User::factory()->unverified()->create();

// Create with relationships
$user = User::factory()
    ->has(Post::factory()->count(5))
    ->create();

The setup: Define states in your factory

// database/factories/UserFactory.php
public function admin()
{
    return $this->state(fn (array $attributes) => [
        'role' => 'admin',
    ]);
}

public function unverified()
{
    return $this->state(fn (array $attributes) => [
        'email_verified_at' => null,
    ]);
}

Translation: Factories let you generate realistic test data without the tedium. It's like having a test data vending machine!

4. Database Transactions: Keep Tests Clean 🧹

The problem: Tests polluting your database

The solution: Use RefreshDatabase trait

use Illuminate\Foundation\Testing\RefreshDatabase;

class PostTest extends TestCase
{
    use RefreshDatabase;

    public function test_something()
    {
        // Create all the data you want
        // It'll be gone after this test runs!
    }
}

What it does: Wraps each test in a database transaction and rolls it back when done. Your database stays pristine! ✨

Alternative: DatabaseMigrations - slower but more thorough. Use it if transactions aren't cutting it.

5. Test Your API Responses Properly 📡

APIs need love too! Here's how to test them right:

public function test_api_returns_posts_with_correct_structure()
{
    $posts = Post::factory(3)->create();

    $response = $this->getJson('/api/posts');

    $response->assertStatus(200)
        ->assertJsonCount(3, 'data')
        ->assertJsonStructure([
            'data' => [
                '*' => ['id', 'title', 'content', 'created_at']
            ]
        ]);
}

public function test_api_returns_validation_errors()
{
    $response = $this->postJson('/api/posts', [
        'title' => '', // Oops, empty!
        'content' => 'Some content'
    ]);

    $response->assertStatus(422)
        ->assertJsonValidationErrors(['title']);
}

Pro tip: Use getJson() and postJson() instead of get() and post() to automatically set JSON headers. Laravel's got your back!

6. Mock External Services (Don't Hit Real APIs) 🎭

The scenario: Your app sends emails or calls external APIs during tests

The problem: Slow tests, API rate limits, spam emails to real addresses!

The fix: Mock it!

public function test_user_registration_sends_welcome_email()
{
    // Don't actually send emails!
    Mail::fake();

    $this->post('/register', [
        'name' => 'John Doe',
        'email' => '[email protected]',
        'password' => 'secret123',
    ]);

    // Assert the email WOULD be sent
    Mail::assertSent(WelcomeEmail::class, function ($mail) {
        return $mail->hasTo('[email protected]');
    });
}

public function test_payment_processing()
{
    // Mock the payment gateway
    Http::fake([
        'payment-api.com/*' => Http::response(['status' => 'success'], 200)
    ]);

    $response = $this->post('/process-payment', [...]);

    $response->assertSuccessful();
}

Available fakes: Mail::fake(), Storage::fake(), Http::fake(), Event::fake(), Queue::fake(), Bus::fake(), Notification::fake()

Translation: Fake external dependencies so tests run FAST and don't have side effects!

Bonus Round: Testing Commandments 📜

1. Name tests like you're explaining to a friend:

// Bad
public function test_post_creation() { }

// Good
public function test_authenticated_user_can_create_post() { }
public function test_guest_cannot_create_post() { }

2. One assertion concept per test:

// Instead of testing everything in one massive test
// Break it into focused tests
test_user_can_login()
test_invalid_credentials_fail()
test_locked_account_cannot_login()

3. Test the happy path AND the sad path:

test_valid_email_passes_validation() // ✅
test_invalid_email_fails_validation() // ❌
test_missing_email_fails_validation() // ❌

The Testing Survival Checklist ✅

Before you merge that PR:

  • Feature tests for main user flows
  • Auth tests (who can do what?)
  • Validation tests (good data and bad data)
  • API structure tests
  • Use factories for test data
  • Mock external services
  • All tests pass locally AND in CI
  • Named tests clearly

Real Talk 💬

Q: "How much should I test?"

A: Test the important stuff! You don't need to test every getter/setter. Focus on business logic, user flows, and anything that would be expensive to break.

Q: "TDD or test after?"

A: Both work! TDD (Test-Driven Development) is great for complex logic. Testing after works for simpler stuff. Pick what keeps you productive!

Q: "My tests are slow!"

A: Use php artisan test --parallel for parallel testing. Also, check if you're hitting real databases or APIs instead of mocking them!

Q: "What about unit tests?"

A: Feature tests give you more bang for your buck in Laravel. Unit tests are great for complex business logic in service classes, but start with feature tests!

The Bottom Line

Testing is like brushing your teeth:

  1. Seems like a chore at first 🦷
  2. Takes a few minutes
  3. Prevents major problems later
  4. Future you will be grateful
  5. Once it's a habit, you feel weird without it

The best time to start testing was yesterday. The second best time is NOW!

Stop gambling with production. Write tests. Deploy confidently. Sleep peacefully. Your users (and your blood pressure) will thank you! 🙏

Want to discuss testing strategies? Hit me up on LinkedIn. I've made all the testing mistakes so you don't have to! 😅

Found this helpful? Star this blog on GitHub for more Laravel goodness!

Now go write some tests before your next deploy! 🚀✨

← Back to all posts