Testing rules with emulator in Firebase - Step-by-Step Execution

Process Flow - Testing rules with emulator

Start Emulator

↓

Load Security Rules

↓

Run Test Requests

↓

Check Request Outcome

↓

Log Success

↓

Stop Emulator

This flow shows starting the emulator, loading rules, running test requests, checking if they pass or fail, logging results, and stopping the emulator.

Execution Sample

Firebase

firebase emulators:exec --only firestore "npm test"
# Test read and write permissions

Starts the Firestore emulator, runs security rule tests, and checks if read/write requests are allowed or denied.

Process Table

Step	Action	Request Type	Rule Check Result	Outcome
1	Start Firestore Emulator	-	-	Emulator running
2	Load Security Rules	-	-	Rules loaded successfully
3	Test Read Request	Read	Allowed by rules	Pass
4	Test Write Request	Write	Denied by rules	Fail
5	Log Results	-	-	Read: Pass, Write: Fail
6	Stop Emulator	-	-	Emulator stopped

💡 All test requests processed; emulator stopped.

Status Tracker

Variable	Start	After Step 3	After Step 4	Final
Emulator Status	Stopped	Running	Running	Stopped
Rules Loaded	No	Yes	Yes	Yes
Read Request Result	N/A	Allowed	Allowed	Allowed
Write Request Result	N/A	N/A	Denied	Denied
Test Outcome	N/A	Pass	Fail	Fail

Key Moments - 2 Insights

Why does the write request fail while the read request passes?

Because the security rules allow reads but deny writes, as shown in execution_table rows 3 and 4.

What happens if the emulator is not started before testing?

The tests cannot run because the emulator must be running to simulate requests, as shown in step 1.

Visual Quiz - 3 Questions

Look at the execution table, what is the outcome of the write request test at step 4?

A Fail

B Skipped

C Pass

D Error

💡 Hint

Check the 'Outcome' column at step 4 in the execution_table.

At which step does the emulator stop running?

A Step 3

B Step 5

C Step 6

D Step 2

💡 Hint

Look at the 'Action' and 'Emulator Status' variable in step 6.

If the security rules allowed writes, how would the 'Test Outcome' variable change after step 4?

A It would remain 'Fail'

B It would change to 'Pass'

C It would be 'Error'

D It would be 'Skipped'

💡 Hint

Refer to variable_tracker 'Test Outcome' after step 4 and consider rule changes.

Concept Snapshot

Testing rules with emulator:
- Start emulator to simulate your database.
- Load your security rules into emulator.
- Run test requests (read/write).
- Check if requests pass or fail based on rules.
- Stop emulator after tests.

Full Transcript

To test Firebase security rules, first start the emulator to simulate your database environment. Then load your security rules into the emulator. Next, run test requests such as reads and writes to see if they are allowed or denied by your rules. Observe the results: if a request is allowed, it passes; if denied, it fails. Finally, stop the emulator to end the testing session. This process helps ensure your rules work as expected before deploying.

Practice

1. What is the main purpose of using the Firebase emulator when testing Firestore security rules?

easy

A. To safely test rules without affecting live data

B. To deploy rules directly to production

C. To speed up Firestore queries in production

D. To backup Firestore data automatically

Solution

1. Step 1: Understand the role of the emulator

   The Firebase emulator creates a safe environment that mimics Firestore without touching live data.

2. Step 2: Identify the benefit of safe testing

   This allows developers to test security rules without risking data loss or exposure in production.

3. Final Answer:

   To safely test rules without affecting live data -> Option A

4. Quick Check:

   Emulator = Safe testing environment [OK]

Hint: Emulator means safe testing, no live data risk [OK]

Common Mistakes:

• Thinking emulator deploys rules to production
• Confusing emulator with data backup tool
• Assuming emulator speeds up production queries

2. Which command correctly starts only the Firestore emulator?

easy

A. firebase start firestore

B. firebase emulators:start --only firestore

C. firebase emulators:run firestore

D. firebase firestore:start

Solution

1. Step 1: Recall the correct Firebase CLI command

   The command to start emulators selectively uses 'firebase emulators:start --only' followed by the service name.

2. Step 2: Match the command to Firestore emulator

   For Firestore only, the command is 'firebase emulators:start --only firestore'.

3. Final Answer:

   firebase emulators:start --only firestore -> Option B

4. Quick Check:

   Correct CLI syntax = firebase emulators:start --only firestore [OK]

Hint: Use --only with service name to start specific emulator [OK]

Common Mistakes:

• Using 'firebase start firestore' which is invalid
• Confusing 'run' with 'start' in command
• Omitting '--only' flag

3. Given this Firestore security rule snippet tested in the emulator:

service cloud.firestore {
  match /databases/{database}/documents {
    match /messages/{msgId} {
      allow read: if request.auth != null;
      allow write: if false;
    }
  }
}

What will happen if an unauthenticated user tries to read a message?

medium

A. Read is denied

B. Write is allowed

C. Read is allowed

D. Write is denied

Solution

1. Step 1: Analyze the read rule condition

   The rule allows read only if request.auth is not null, meaning user must be authenticated.

2. Step 2: Check the user's authentication status

   The user is unauthenticated, so request.auth is null, failing the condition.

3. Final Answer:

   Read is denied -> Option A

4. Quick Check:

   Unauthenticated read = denied [OK]

Hint: Read allowed only if user is authenticated [OK]

Common Mistakes:

• Assuming read is allowed without authentication
• Confusing read and write permissions
• Ignoring the request.auth check

4. You wrote this rule in the emulator but all writes are failing:

allow write: if request.auth.uid == userId;

What is the likely error causing the failure?

medium

A. request.auth.uid is always null in emulator

B. Emulator does not support write rules

C. Write rules cannot use '==' operator

D. The variable 'userId' is not defined in the rule context

Solution

1. Step 1: Check the rule variable usage

   The rule compares request.auth.uid to userId, but userId is not defined or extracted from the document path or data.

2. Step 2: Understand rule variable scope

   Variables like userId must be defined in the path or request data; otherwise, the condition fails.

3. Final Answer:

   The variable 'userId' is not defined in the rule context -> Option D

4. Quick Check:

   Undefined variable causes rule failure [OK]

Hint: Ensure all variables in rules are properly defined [OK]

Common Mistakes:

• Assuming emulator nullifies request.auth.uid
• Thinking '==' is invalid in rules
• Believing emulator ignores write rules

5. You want to test that only users can write their own profile document in the emulator. The document path is /users/{userId}. Which rule correctly enforces this and can be tested in the emulator?

hard

A. allow write: if true;

B. allow write: if request.auth.uid != userId;

C. allow write: if request.auth.uid == userId;

D. allow write: if request.auth != null;

Solution

1. Step 1: Match userId from document path

   In rules, userId is a variable from the path /users/{userId} and can be used in conditions.

2. Step 2: Enforce write only if authenticated user matches userId

   The condition 'request.auth.uid == userId' ensures only the user can write their own profile.

3. Final Answer:

   allow write: if request.auth.uid == userId; -> Option C

4. Quick Check:

   User writes own doc = request.auth.uid == userId [OK]

Hint: Match auth uid to path userId for user-specific writes [OK]

Common Mistakes:

• Using '!=' instead of '==' causing wrong access
• Allowing any authenticated user to write all profiles
• Setting rule to always true, no security