Every engineer has two journeys:
One is the work we ship.
The other is the growth we quietly build behind the scenes.

The Engineer’s Logs is my attempt to capture that second journey.

These notes and logs are rough and candid, meant for me to revisit over time. But I figured—why not share them here too!

🔎 This Week’s (Tech and other) Musings

🎧 What I Consumed

• Zepto launches Atom, giving brands real-time insights into their product performance on the platform.

• Databricks ventures into the OLTP space with its acquisition of Neon, an AI-assisted, cloud-native, serverless Postgres engine. With Neon, AI agents can spin up temporary Postgres branches to run, test, and discard without human input.

🎧 What I Learnt

• I worked on unit testing for a couple of APIs. Learnt a couple of things:

  • The flow I followed for setup was:

    • Added the project’s root directory to sys.path so imports work everywhere without ugly relative paths.

    • For isolation, every test runs against its own in-memory SQLite database.

    • The helper fresh_db (an asynccontextmanager in conftest.py) does the heavy lifting. An async context manager bundles “setup → yield resource → teardown” for asynchronous code. It produces an object you use with “async with” anywhere in your application or tests.

      • before yield: creates the SQLite engine, builds all tables, then opens and returns an AsyncSession;

      • after the test exits: disposes the engine, wiping the database.

    • db_session is a pytest fixture simply yields fresh_db’s session. A pytest fixture is a reusable, plug-and-play helper that prepares something your test needs and then cleans it up afterward. Using the db_session as an argument inside your test implies:

      • Pytest inspects the test function’s parameter list.

      • It sees a parameter named db_session and looks for a fixture with that name.

      • It runs the fixture, which in turn runs fresh_db, creates a brand-new AsyncSession, and yields it.

      • The yielded session object is fed into the test function as the argument db_session.

      • After the test body completes (pass or fail), execution resumes after the yield inside the fixture, which closes/disposes the SQLite engine—so nothing leaks into the next test.

    • Most test files also declare a small seeded_session helper. It calls fresh_db, pre-populates rows that the particular test needs, then yields the session—so every test starts with relevant data.

    • During startup we register a few MySQL-style SQL functions with SQLite so that any raw SQL used in the codebase runs unchanged.

    •       async test  ───>  requests fixture  ───>  fixture enters context manager
                          ^                       |
                          |                       v
                          <────  uses session  <─── yields session
      

  • All input and expected data was separated out into a data file for tests. This made it easy to tweak the parameters.

  • To summarise:

    • Pytest finds the file →

    • creates a clean SQLite database →

    • seeds a few rows →

    • runs the business-logic function you’re interested in →

    • checks the return values/query results →

    • tears everything down