This page needs a newer browser to run its tools. You can still read everything here.

Building Web Apps with Laravel Module 12

Testing Laravel applications interview questions

Interview questions on testing Laravel applications: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.

15 questions: 4 warm-ups and 11 with model answers · Levels: Fresher to senior

Warm-up questions

Short questions with short answers, each answered in full.

Fresher

In a Laravel project, how does a unit test differ from a feature test, and which kind should most tests be?

Answered in the lesson Testing with Pest and PHPUnit
Fresher to mid

Why does the second test of a class find the students table empty after the first test created a student?

Answered in the lesson HTTP tests and database tests
Fresher to mid

How does a fake differ from a mock in a Laravel test?

Answered in the lesson Fakes, mocks and time travel
Fresher to mid

What can static analysis find in a Laravel app that its feature tests miss?

Answered in the lesson Browser tests, static analysis and CI

Questions with model answers

What each question tests, the first step of a good answer and the follow-ups to expect.

Fresher to mid

A developer ran a deployment script on their laptop to try it out. Afterwards, php artisan test passed as usual, but their local database was empty. Explain what most likely happened and what you would change so that it cannot happen again.
What it tests

Knowing that a cached configuration replaces the testing values of phpunit.xml, that RefreshDatabase rebuilds whatever database the configuration names, and which guards stop it.

First step

Ask what the script ran: a deployment usually runs php artisan config:cache. Then check whether bootstrap/cache/config.php exists, and run one test that prints app()->environment() and the database name.
Follow-ups
- Why did the tests stay green if they ran against the wrong database?
- Which guard would you put in the project, and which in CI?
- When does a value in the shell override phpunit.xml even without a cached configuration?
From the lesson Testing with Pest and PHPUnit
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.
Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
Pro pass · 1 week₹79$2.99
30 days₹179$5.99
1 year₹1,699$45
One payment; a pass never renews. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
Choose a pass I have a licence key
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

Your team wants to move a Laravel 13 project's 400 PHPUnit tests to Pest. Production runs PHP 8.3 today and moves to PHP 8.4 next quarter. Plan the move: which versions, which commands, in what order, and how you prove that no test was lost on the way.
What it tests

Reading version constraints (Pest 4 on PHPUnit 12.5.33, Pest 5 on PHPUnit 13 and PHP 8.4), using drift safely, and comparing test and assertion counts before and after.

First step

Write down the constraints first: the PHP version of every place the tests run, and the PHPUnit version the project locks. They decide whether Pest 5 is possible now or only after the PHP upgrade.
Follow-ups
- Why does composer require pestphp/pest fail on a fresh Laravel 13 project?
- What would you compare to prove the converted suite still tests the same things?
- Would you convert all files at once, or folder by folder, and why?
From the lesson Testing with Pest and PHPUnit
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

A code review finds that a Laravel endpoint listing each family's fee instalments has returned the guardian's phone number in every item for weeks, while all of its tests stayed green. Explain how the tests missed it and what you would change in the tests and in the code.
What it tests

Knowing which JSON assertions check single values and which check a whole object, and treating every field an endpoint returns as a decision made in the code and pinned by a test.

First step

Read the endpoint's tests and list what each one asserts about the response. Then compare that list with every key a real response carries: any key that no test mentions is a field the suite cannot see.
Follow-ups
- Would you fix this in the tests, in the code, or in both, and why?
- How would you check the project's other endpoints for the same problem?
- Which data in a fee system would you keep out of an API answer, and why?
From the lesson HTTP tests and database tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Fresher to mid

After a redesign of the instalment form, staff get a 419 Page Expired page every time they save, yet every feature test of the form stays green. Explain why the tests could not catch it, and which test you would add so that it cannot happen again.
What it tests

Knowing what a 419 means in Laravel, how the CSRF check behaves while tests run, and the difference between testing the framework's middleware and testing your own page.

First step

Open the form's page in the browser's developer tools and look for a hidden _token field inside the form and a session cookie on the response. A 419 means the token was missing or did not match, so decide which of the two it is before you change anything.
Follow-ups
- Why does a test that posts the form without a token still succeed?
- How would you make one test meet the real check?
- What else besides a missing token field can cause a 419 in production?
From the lesson HTTP tests and database tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

A Laravel project has 600 passing tests and 85 % line coverage, yet two bugs in fee calculations reached production within a few months. How would you measure how good the suite really is, and how would you turn the result into better tests?
What it tests

Knowing what line coverage does and does not prove, how to measure whether tests notice deliberate mistakes, and how each mistake they miss becomes the next test.

First step

Take one of the two escaped bugs and put it back on a branch, then run the suite. If every test stays green, the suite cannot see that kind of mistake, and the real question becomes how many more like it exist.
Follow-ups
- Why can 85 % line coverage and a weak suite exist together?
- How would you choose which deliberate mistakes to try first in a fee module?
- Would you add such a measurement to CI, and with what threshold?
From the lesson HTTP tests and database tests
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

After a deploy, some guardians got the same fee reminder SMS twice on one morning, yet every reminder test is green. How would you find the cause, and which tests would you add so that it cannot happen again?
What it tests

Knowing what makes a scheduled command safe to run twice, how a mock's once() and a fake's assertSentTimes() count sends over two runs, and why a test of one run cannot see a second.

First step

Count how many times the command ran that morning: the scheduler's log, the deploy's own steps and any manual run. Then read what stops a second run from sending again, such as a reminded_at column that the query checks.
Follow-ups
- Why did the green tests not catch it?
- How would you keep the command safe when two servers run the scheduler?
- Would you mark the instalment before or after the SMS goes out, and why?
From the lesson Fakes, mocks and time travel
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Fresher to mid

A reminder test fails in the nightly CI run at 02:00 IST and succeeds every time a developer runs it during the day. Nobody changed the code. Explain the most likely cause and how you would make the test deterministic.
What it tests

Recognising a test whose result depends on the time of day, working out which clock and calendar the test and the code each read, and making the test give one answer at any hour.

First step

Read how the test builds its dates and how the code builds its own, and write down which clock and which timezone each one reads. A difference between the two is the first place to look.
Follow-ups
- How would you prove the cause without waiting for the next night?
- Why is freezeTime() on its own not a fix?
- What else makes a test succeed in the day and fail at night?
From the lesson Fakes, mocks and time travel
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Every feature test of a payment flow is green with Bus::fake(), yet in production the job that copies payments into the ledger fails on every payment. How did the suite miss it, and how would you change the tests?
What it tests

Knowing what a bus or queue fake records and what it never runs, and how to test the code of a job that every feature test fakes.

First step

Read the job's error in the failed jobs table, then look for a test that calls that job's handle(). If every test fakes the bus, no test has ever run the job's code.
Follow-ups
- Why not drop Bus::fake() and let the jobs run on the sync queue instead?
- What would the job's own test fake, and what would it assert?
- How would you find the other faked jobs that have no test of their own?
From the lesson Fakes, mocks and time travel
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

Every feature test of a Laravel app is green, yet a queued job crashed in production on its first run with a call to an undefined method. Which checks would you add to the project, and where would each run, so that the next mistake of this kind stops before the merge?
What it tests

Knowing what a faked queue hides, what static analysis can show without running code, how to bring it into an existing project, and how CI makes every check unavoidable.

First step

Start with why no test ran the job: look for Bus::fake() or Queue::fake() in the tests that dispatch it, and for a test that calls the job's own handle(). Then run Larastan on the job's file and read what it reports.
Follow-ups
- The first Larastan run on the whole app reports 300 errors in old code. What do you do?
- Which level would you start at, and why not the highest?
- How do you make sure nobody merges while the analysis is red?
From the lesson Browser tests, static analysis and CI
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 4 minutes
Mid to senior

A Dusk test creates a student with a factory, opens the student's page in Chrome and sees an empty list. The same steps written as an HTTP test are green. What is the most likely cause, and how would you fix the browser test?
What it tests

Understanding how a browser test reaches the application, where the rows a test writes are visible, and which database reset fits each kind of test.

First step

Compare where the rows are written with where the page reads them: which connection and which transaction the test uses, and which process answers the request that Chrome sends.
Follow-ups
- Would the same test pass if it were written with Pest's browser plugin, and why?
- Which reset would you choose for a suite of 200 browser tests, and why?
- How would you give every browser test the rows it needs without slowing the suite down?
From the lesson Browser tests, static analysis and CI
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
Mid to senior

composer.json says php ^8.3, so a pull request adds PHP 8.3 to the CI matrix. The 8.3 job fails at composer install while the 8.4 and 8.5 jobs are green. Explain what happened and the options you would give the team.
What it tests

Knowing that composer install takes its versions from the lock file, how to find what blocks an older PHP, and how to make the lock, the matrix and the servers agree.

First step

Read the failing step's error first: it names a package and the PHP version that package needs. Then compare what composer.json allows with what composer.lock actually holds.
Follow-ups
- How would you list every locked package that needs a newer PHP?
- What changes if the production servers still run PHP 8.3?
- Why not delete composer.lock in CI and let Composer resolve on each PHP version?
From the lesson Browser tests, static analysis and CI
Model answer, Pro.
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes

The lessons of this module

Testing with Pest and PHPUnit Free lesson, Pro answers: 15 minutes
HTTP tests and database tests Free core, Pro depth: 6 of 20 minutes free
Fakes, mocks and time travel Free core, Pro depth: 6 of 20 minutes free
Browser tests, static analysis and CI Free core, Pro depth: 5 of 20 minutes free

All Building Web Apps with Laravel interview questions · The Building Web Apps with Laravel track

Warm-up questions

In a Laravel project, how does a unit test differ from a feature test, and which kind should most tests be?

Why does the second test of a class find the students table empty after the first test created a student?

How does a fake differ from a mock in a Laravel test?

What can static analysis find in a Laravel app that its feature tests miss?

Questions with model answers

A developer ran a deployment script on their laptop to try it out. Afterwards, php artisan test passed as usual, but their local database was empty. Explain what most likely happened and what you would change so that it cannot happen again.

Your team wants to move a Laravel 13 project's 400 PHPUnit tests to Pest. Production runs PHP 8.3 today and moves to PHP 8.4 next quarter. Plan the move: which versions, which commands, in what order, and how you prove that no test was lost on the way.

A code review finds that a Laravel endpoint listing each family's fee instalments has returned the guardian's phone number in every item for weeks, while all of its tests stayed green. Explain how the tests missed it and what you would change in the tests and in the code.

After a redesign of the instalment form, staff get a 419 Page Expired page every time they save, yet every feature test of the form stays green. Explain why the tests could not catch it, and which test you would add so that it cannot happen again.

A Laravel project has 600 passing tests and 85 % line coverage, yet two bugs in fee calculations reached production within a few months. How would you measure how good the suite really is, and how would you turn the result into better tests?

After a deploy, some guardians got the same fee reminder SMS twice on one morning, yet every reminder test is green. How would you find the cause, and which tests would you add so that it cannot happen again?

A reminder test fails in the nightly CI run at 02:00 IST and succeeds every time a developer runs it during the day. Nobody changed the code. Explain the most likely cause and how you would make the test deterministic.

Every feature test of a payment flow is green with Bus::fake(), yet in production the job that copies payments into the ledger fails on every payment. How did the suite miss it, and how would you change the tests?

Every feature test of a Laravel app is green, yet a queued job crashed in production on its first run with a call to an undefined method. Which checks would you add to the project, and where would each run, so that the next mistake of this kind stops before the merge?

A Dusk test creates a student with a factory, opens the student's page in Chrome and sees an empty list. The same steps written as an HTTP test are green. What is the most likely cause, and how would you fix the browser test?

composer.json says php ^8.3, so a pull request adds PHP 8.3 to the CI matrix. The 8.3 job fails at composer install while the 8.4 and 8.5 jobs are green. Explain what happened and the options you would give the team.