How do you test browser storage corruption scenarios?

Question

QA Hacks Team · Accepted Answer

Testing browser storage corruption scenarios is a crucial fault-injection exercise, vital for robust application development. The core strategy involves programmatically manipulating browser storage (`localStorage`, `sessionStorage`, `IndexedDB`) to introduce malformed or excessive data, then asserting the application's resilience.

**1. Core Strategy: Programmatic Manipulation**
Modern automation frameworks (e.g., Playwright, Cypress) provide direct access to the browser's JavaScript execution context. We leverage this to inject arbitrary scripts that interact with storage APIs.

**2. Types of Corruption & Injection Techniques:**
*   **Malformed JSON/String Data:**
    *   **Scenario:** Storing non-JSON strings where JSON is expected, or incomplete JSON.
    *   **Technique:** Use `page.evaluate()` (Playwright) or `cy.window().then()` (Cypress) to execute `localStorage.setItem('key', '{malformed_json')` or `sessionStorage.setItem('anotherKey', 'invalid data')`.
*   **Exceeding Storage Quotas:**
    *   **Scenario:** Attempting to store data larger than the browser's allocated quota (typically 5-10MB for `localStorage`/`sessionStorage`).
    *   **Technique:** Repeatedly store large strings until a `QuotaExceededError` is triggered, then observe app behavior.
    ```javascript
    // Playwright pseudo-code for quota test
    await page.evaluate(() => {
      let largeString = 'a'.repeat(1024 * 500); // 0.5 MB
      try {
        for (let i = 0; i < 20; i++) { // Attempt to exceed 10MB
          localStorage.setItem(`item${i}`, largeString);
        }
      } catch (e) {
        if (e.name === 'QuotaExceededError') {
          console.log('Quota exceeded as expected.');
        } else {
          throw e;
        }
      }
    });
    ```
*   **Invalid `IndexedDB` Data:**
    *   **Scenario:** Storing objects with unexpected schemas or malformed values in IndexedDB.
    *   **Technique:** Use `page.evaluate()` to open an IndexedDB, create a transaction, and `put` data that violates expected data types or schema constraints.

**3. Test Flow & Verification:**
1.  **Navigate:** Go to the relevant application page.
2.  **Inject Corruption:** Execute JavaScript to corrupt the target storage mechanism.
3.  **Reload/Re-render:** Optionally, reload the page or trigger a component re-render to simulate a fresh load with corrupted data.
4.  **Verify Application Behavior:**
    *   **UI Assertions:** Check for expected error messages, fallback UI states, or default data rendering.
    *   **Console Logs:** Monitor for `console.error` or `console.warn` messages related to parsing failures.
    *   **Network Requests:** Ensure no incorrect data is sent to the backend due to client-side corruption.
    *   **Application State:** Verify the app doesn't crash, enter an infinite loop, or behave unpredictably.
    *   **Recovery:** If the app has self-healing logic (e.g., clearing corrupted storage), assert its successful execution.

**4. Framework Architecture:**
*   **Custom Commands/Helpers:** Encapsulate corruption logic into reusable functions (e.g., `cy.corruptLocalStorage('key', 'data')`, `page.injectIndexedDBCorruption(data)`).
*   **Data-Driven Testing:** Use data tables to define various corruption scenarios (valid/invalid keys, different malformed data types).
*   **CI/CD Integration:** Integrate these tests into the CI/CD pipeline to catch regressions early.

This systematic approach ensures the application gracefully handles unexpected client-side storage states, enhancing overall robustness.

### Speaking Blueprint (3-Minute Verbal Response):
[The Hook]
In an era where modern web applications heavily rely on client-side state management, ensuring data integrity in browser storage is absolutely paramount for delivering a robust user experience and maintaining overall engineering efficiency. Our approach leverages advanced automation techniques to rigorously test these often-overlooked and critical scenarios, moving beyond simple functional validation to true application resilience.

[The Core Execution]
When tackling browser storage corruption, we treat it as a critical fault injection exercise within our automation framework. The core idea is to programmatically manipulate browser storage – `localStorage`, `sessionStorage`, and `IndexedDB` – directly from our test scripts. For instance, using tools like Playwright or Cypress, we can leverage their capability to execute arbitrary JavaScript within the browser's context. This allows us to inject deliberately malformed JSON strings where a structured object is expected, exceed storage quotas by flooding `localStorage` with large data, or even simulate corrupted key-value pairs in `IndexedDB`. Once the 'corrupted' state is injected, the test then meticulously validates the application's resilience. This involves asserting specific UI error messages, verifying that no incorrect data is inadvertently sent to the backend, monitoring console logs for critical JavaScript

How do you test browser storage corruption scenarios?

📋 Interview Context

Overview

Interview Question:

Expert Answer:

Speaking Blueprint (3-Minute Verbal Response):

Continue Learning: Up Next

How do you analyze defect leakage across releases?

How do you assess API dependencies before deployment?

How do you assess API dependency risks before releases?