test: add an ergonomic way to access the test database for debugging#19371
Conversation
mafredri
left a comment
There was a problem hiding this comment.
I'd like to better understand how this is to be used. For instance, if you have a quick test I think it's unlikely you'll have time to connect to the database, right?
Why do you need to connect to the live database? There's also the dump database on failure option that can be enabled, which gives you the state of the database when it failed. That isn't sufficient for your use-case?
Is the purpose explicitly to allow outputting the DSN without modifying the test (i.e. not needing to add the option to output it and/or dump the db)?
johnstcn
left a comment
There was a problem hiding this comment.
What's the expected flow here? Let's say you have an existing test that fails. I would imagine it would make sense to log the DSN and then wait for the user to continue once they've successfully connected.
|
Expected flow:
Dumping the database on test failure is useful, but still requires more friction than this in my opinion. |
|
Thanks @SasSwart, I think using dlv was the context I was missing, makes much more sense now 👍🏻. (PS. I think your commit didn't get pushed, or GitHub hasn't updated yet |
Accessing the database during debugging currently requires either spinning up a separate PostgreSQL instance or inspecting memory to retrieve the DSN—both of which add unnecessary friction. While the test suite already provisions a database by default, connecting to it for manual inspection or debugging is not straightforward.
This change introduces a clearer and more accessible way to surface the DSN during debugging sessions, allowing developers to connect to the test database directly without relying on external infrastructure or ad hoc methods.
Expected Usage: