(Kind of) REPL Driven Development
At work I'll regularly connect my REPL to our dev and staging environments (via a DB proxy) to explore & debug issues.
Most snippets/queries I execute regularly are already there in my REPL history, so are quick and easy to find. Combine this with a PYTHONSTARTUP file to import a bunch of commonly used modules means everything I typically need is already there.
Instead of having to write any SQL, I get to use the same style ORM queries as the codebase I'm working on. From there I'm able to explore/evaluate anything in the code-base.
Here I'm able to make any code changes locally, reload and re-execute code until things work. This makes the data on dev/staging coupled with my application code feel less like some static artifact that gets deployed, and more like a living/evolving thing I'm able to poke at and introspect.
Earlier this week I was told something has gone wrong with the sync_status for a user. To investigate, I usually find it more useful to fire up my REPL, run: db.session.get(User, <ID>) and start exploring from there.
At this point, I've not written any tests, I've not looked at any dashboards, I've not looked at any logs, I've not looked for any stack traces, I've not checked the data in a DBMS, I've not written any SQL queries. In fact I've not particularly used my brain at all.
I added a breakpoint inside the sync_status property, reloaded my REPL and re-evaluated. This dropped me into a pdb session, from here I started poking around to see exactly what was failing.
Once I figured out what was failing, I made the necessary change, reloaded my REPL again and checked sync_status, to my satisfaction it was now working as expected for that user.
Did I retrospectively added a failing test? Have I abused this power to fudge demos? 1 I guess you'll never know 😉
Why I like this
I don't have to jump through hoops trying to reproduce / setup test data for particular issues, the failing state is right there.
Because I'd connected my REPL to dev and actually tested against the 'live' failing data (and not some fake reproduction), there'll be no surprises when my code eventually gets deployed and my code turns out not to have fixed the issue.
Me watching you not use a REPL
I'm trying to think how I'd go about debugging the same issue without this kind of workflow...
Imagine if my language of choice didn't have a REPL (or worse) if my organisation didn't grant me direct access to dev/staging.
Certainly not having this kind of power makes this kind of on-the-fly borderline impossible.
For legal reasons this is a joke.↩