Skip to content

test: add an ergonomic way to access the test database for debugging #19371

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 6 commits into from
Aug 15, 2025
Merged

test: add an ergonomic way to access the test database for debugging #19371

merged 6 commits into from
Aug 15, 2025

Conversation

SasSwart
Copy link
Contributor

@SasSwart SasSwart commented Aug 15, 2025 •
edited
Loading

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:

  1. Debug using dlv or the IDE.
  2. Step through line by line and determine that a query isn't doing what you'd expect
  3. No further insight to be gained at the Go level
  4. The next place to test is to connect directly to the database while it is in the exact state that the test has produced just before running the query
  5. Rerun the test with this option enabled and your breakpoint set right before the questionable query runs
  6. Connect to the database and inspect or troubleshoot as you need to

@SasSwart SasSwart requested review from mafredri and hugodutka August 15, 2025 07:26
@SasSwart SasSwart marked this pull request as ready for review August 15, 2025 07:29
mafredri
mafredri reviewed Aug 15, 2025
View reviewed changes
Copy link
Member

@mafredri mafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
johnstcn reviewed Aug 15, 2025
View reviewed changes
Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@SasSwart
Copy link
Contributor Author

Expected flow:

  1. Debug using dlv or the IDE.
  2. Step through line by line and determine that a query isn't doing what you'd expect
  3. No further insight to be gained at the Go level
  4. The next place to test is to connect directly to the database while it is in the exact state that the test has produced just before running the query
  5. Rerun the test with this option enabled and your breakpoint set right before the questionable query runs
  6. Connect to the database and inspect or troubleshoot as you need to

Dumping the database on test failure is useful, but still requires more friction than this in my opinion.

@SasSwart SasSwart requested review from mafredri and johnstcn August 15, 2025 08:37
@mafredri
Copy link
Member

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 ¯\_(ツ)_/¯)

johnstcn
johnstcn approved these changes Aug 15, 2025
View reviewed changes
Copy link
Member

@johnstcn johnstcn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍

mafredri
mafredri reviewed Aug 15, 2025
View reviewed changes
mafredri
mafredri approved these changes Aug 15, 2025
View reviewed changes
Copy link
Member

@mafredri mafredri left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, great addition 👍🏻

@SasSwart SasSwart merged commit a9f607a into main Aug 15, 2025
31 checks passed
@SasSwart SasSwart deleted the jjs/test-db-dsn-log branch August 15, 2025 09:25
@github-actions github-actions bot locked and limited conversation to collaborators Aug 15, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Reviewers

@mafredri mafredri mafredri approved these changes

@johnstcn johnstcn johnstcn approved these changes

@hugodutka hugodutka Awaiting requested review from hugodutka

Assignees

@SasSwart SasSwart

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@SasSwart @mafredri @johnstcn
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy