"DBI connect failed" when the test suite has no production credentials: choosing between DBD::Mock and skip_all

Answer the question first

When a test run has no production database credentials, the preferred behaviour is to skip the tests that need a real database rather than let a hard connection failure surface. The real DBI code path should only be exercised when an explicit test DSN is supplied. For unit‑level tests that only need to exercise SQL generation, a DBD::Mock handle is acceptable, but those tests should be marked as mocked and not count as failures if the real database is unavailable.

Why skip is the safer default

• It makes the CI output clear: “skipped” signals a missing environment, not a defect in the code.
• It preserves the real driver’s connection logic, so any driver‑specific bugs (e.g. wrong DSN format, timeout handling) are caught when a DSN is present.
• It avoids false positives from a mock that may not emulate driver‑specific error codes or transaction semantics.

How to combine both modes in a single test suite

1. Detect a test DSN at the top of each test file or in a shared helper:

   use Test::More;
   my $dsn = $ENV{TEST_DB_DSN} // '';
   
   unless ($dsn) {
       skip_all('No TEST_DB_DSN provided – skipping live‑DB tests');
   }
   

2. For tests that only validate SQL or schema generation, use DBD::Mock:

   use DBD::Mock;
   my $dbh = DBI->connect("dbi:Mock:dbname=test", undef, undef, {
       RaiseError   => 1,
       AutoCommit   => 1,
   });
   # set canned rows
   $dbh->{Mock} = [ { id => 1, name => 'Alice' } ];
   

3. For tests that must exercise a real database, guard the entire file with the DSN check. If a DSN is present, connect normally; otherwise the file is skipped entirely.

When to treat missing credentials as a hard failure

Only if the test suite is explicitly designed to run against a *known* disposable database (e.g. a Docker‑based test instance that is always started by the CI pipeline) should the absence of credentials be considered a hard failure. In most development workflows, however, a missing DSN should be a skip to avoid confusing developers and CI operators.

Practical verification steps

1. Run prove -v without TEST_DB_DSN and confirm that the output shows skipped for the relevant tests.
2. Set TEST_DB_DSN to a lightweight SQLite DSN (e.g. dbi:SQLite:dbname=:memory:) and run prove -v again; the same tests should now be executed and pass or fail based on real DB behaviour.
3. If you want to keep mock tests running in all environments, place them in a separate file (e.g. t/mock_sql.t) that never checks for TEST_DB_DSN.

Summary

Use skip_all when no test DSN is available; use DBD::Mock only for isolated SQL‑generation tests. This hybrid approach keeps the test suite honest about configuration issues while still allowing thorough driver‑specific testing when a disposable database is supplied.