Testing rules with emulator in Firebase - Time & Space Complexity
When testing Firebase security rules with an emulator, we want to know how the time to run tests changes as we add more test cases.
How does the number of tests affect the total time spent checking rules?
Analyze the time complexity of running multiple rule tests using the Firebase emulator.
const { initializeTestEnvironment } = require('@firebase/rules-unit-testing');
async function runTests(n) {
const testEnv = await initializeTestEnvironment({ projectId: 'demo-project' });
for (let i = 0; i < n; i++) {
const db = testEnv.authenticatedContext('user' + i).firestore();
await db.collection('messages').add({ text: 'Hello ' + i });
}
await testEnv.cleanup();
}
This code runs n tests where each test tries to add a message to Firestore using the emulator.
Look at what repeats as n grows.
- Primary operation: Adding a document to Firestore via the emulator.
- How many times: Exactly n times, once per loop iteration.
Each test adds one document, so the total operations grow directly with n.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 document adds |
| 100 | 100 document adds |
| 1000 | 1000 document adds |
Pattern observation: The number of operations grows in a straight line as n increases.
Time Complexity: O(n)
This means the time to run all tests grows directly in proportion to the number of tests.
[X] Wrong: "Running more tests won't affect total time much because the emulator is fast."
[OK] Correct: Each test still runs separately and takes time, so more tests add up linearly.
Understanding how test time grows helps you plan efficient testing and shows you think about scaling in real projects.
"What if we ran tests in parallel instead of one after another? How would the time complexity change?"