# The Engineer's Logs - #3

> **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.
            
        * ```plaintext
                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