🗄️ Mocking Storage & Caching in Jest — Expense Tracker Edition

💡 Why Storage Is Annoying To Test

Let’s be honest — storage is emotional.

When a function breaks, you fix it.

When an API fails, you retry it.

But when storage lies to you?

When you save something… and it comes back different?

That is BETRAYAL.

Every dev has felt this:

• “Why is my saved list empty?”
• “Why does this test pass only on Tuesdays?”
• “Who told localStorage to remember OLD data?”

Real apps read, write, update, and forget values constantly.

Tests must not depend on that chaos.

Tests need memory that behaves perfectly every time —

even if your users don’t. 😌

So today we fake it all.

🧩 Step 1 — Our Storage Layer

📁 expenseStorage.js

exports.saveExpenses = (list) => {
  localStorage.setItem('expenses', JSON.stringify(list));
};

exports.loadExpenses = () => {
  const data = localStorage.getItem('expenses');
  return data ? JSON.parse(data) : [];
};

Looks harmless.

Until you run ten tests and all ten start sharing the same saved data.

That’s when you realize:

“I am not testing storage… storage is testing me.”

⚙️ Step 2 — Mocking localStorage (The Only Safe Way)

In Node, there is no real localStorage, so we create our own:

📁 expenseStorage.test.js

beforeEach(() => {
  global.localStorage = {
    setItem: jest.fn(),
    getItem: jest.fn(),
  };
});

const { saveExpenses, loadExpenses } = require('./expenseStorage');

test('should save expenses', () => {
  const fake = [{ amount: 200 }];

  saveExpenses(fake);

  expect(localStorage.setItem).toHaveBeenCalledWith(
    'expenses',
    JSON.stringify(fake)
  );
});

test('should load expenses', () => {
  localStorage.getItem.mockReturnValue(JSON.stringify([{ amount: 300 }]));

  const result = loadExpenses();

  expect(result[0].amount).toBe(300);
});

Now storage behaves.

It acts exactly how you want…

not how the browser wants.

It is the first time storage has ever respected you. 😌

⚙️ Step 3 — Mocking AsyncStorage (React Native)

jest.mock('@react-native-async-storage/async-storage', () => ({
  setItem: jest.fn(),
  getItem: jest.fn().mockResolvedValue(null),
  removeItem: jest.fn(),
}));

No device emulator.

No real storage.

No leftover data from your last test run.

React Native devs usually learn this trick the hard way.

YOU DID NOT.

🧠 Step 4 — Mocking In-Memory Cache

Caching is basically your app saying:

“I’ll remember this for later.”

And sometimes it does.

Sometimes it does not.

📁 expenseCache.js

let cache = null;

exports.setCache = (data) => {
  cache = data;
};

exports.getCache = () => cache;

Test:

const { setCache, getCache } = require('./expenseCache');

test('should store and retrieve cache', () => {
  setCache({ amount: 150 });

  const result = getCache();

  expect(result.amount).toBe(150);
});

Simple. Predictable. No memory leaks.

No “why is this test receiving data from last week???”

Real-World Psychology

Your reader doesn’t stay because the code is correct.

They stay because the experience is familiar.

Everyone has dealt with:

• stale cache
• missing saved values
• mysterious broken sessions
• tests passing only after restart
• data randomly reappearing

When you talk about things they’ve lived through…

they feel seen.

They keep reading.

This is how you create loyal readers, not just page views.

✅ Summary

Today, our Expense Tracker became smarter than memory itself.

It learned how to:

🗄️ Mock localStorage
📦 Mock AsyncStorage
 🧠 Mock in-memory caching
✨ Avoid sticky data between tests

Your tests no longer depend on yesterday.

They run clean, isolated, and predictable —

the way tests should be.

Next post → we go into mocking failures, retries, and network disasters — the stuff every dev secretly fears but must master.