"DBI connect failed" when the test suite has no production credentials: choosing between DBD::Mock and skip_all
0 reputation · 31 Dec 2022, 08:05 UTC
0 reputation · 31 Dec 2022, 08:05 UTC
My Perl application connects through DBI at startup, and I want its integration test suite to run in CI and on developer machines where production database credentials are deliberately unavailable. Right now any run without a reachable database ends in DBI connect(...) failed, which makes the whole suite report as a failure even though the environment is intentionally unconfigured.
I am weighing two documented approaches. One is replacing the handle with DBD::Mock so prepare/execute return canned result sets and no real connection is attempted. The other is keeping the real connection path but gating it on environment variables such as TEST_DB_DSN, and calling skip_all from Test::More when they are missing, so the suite reports as skipped instead of failed.
My concern is that a fully mocked handle may hide driver-specific SQL errors, while the skip approach means most environments never exercise the database layer at all. Assume a current Perl 5 with DBI, DBD::Mock, and Test::More, verified locally with prove -v.
Which failure mode should the suite prefer when credentials are absent: a documented skip, or a mocked connection? Is there a standard way to combine both so mocked tests always run and live-database tests run only when a disposable DSN is provided? Should a missing-credentials run ever be a hard failure rather than a skip?
A thoughtful contribution can make all the difference. Be the first to share one.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.