Dual-target TestCompat pattern: run same SQL against pglike and real PostgreSQL #5

New issue

Open

opened 2026-08-07 14:22:10 +00:00 by hum3 · 0 comments

hum3 commented

2026-08-07 14:22:10 +00:00

Owner

Goal

Add a TestCompat pattern that runs identical SQL statements against both pglike (SQLite-backed) and a real PostgreSQL instance to catch translation divergence.

Approach

Parameterized Go tests, not a custom SQL test framework (replaces the pgTAP idea from #2):

func TestCompat(t *testing.T) {
    for _, db := range testDBs(t) { // pglike + optionally real PG
        t.Run(db.Name, func(t *testing.T) {
            // same SQL, same assertions
        })
    }
}

testDBs(t) returns pglike always; adds real PG when a connection string is available (e.g. PG_TEST_DSN env var)
CI can run pglike-only; local dev or a separate CI job adds real PG
Add compat tests incrementally when translation bugs are discovered

Why not pgTAP

High implementation cost for a custom SQL test framework
Without EXECUTE, the most interesting assertions (throws_ok, cmp_ok) are impossible
Most pgTAP functions (roles, schemas, triggers) are irrelevant to pglike
Go-native dual-target tests achieve the same goal with less machinery

See #2 for the original pgTAP discussion.

Migrated from Codeberg: originally #5, opened 2026-03-19.

## Goal Add a `TestCompat` pattern that runs identical SQL statements against both pglike (SQLite-backed) and a real PostgreSQL instance to catch translation divergence. ## Approach Parameterized Go tests, not a custom SQL test framework (replaces the pgTAP idea from #2): ```go func TestCompat(t *testing.T) { for _, db := range testDBs(t) { // pglike + optionally real PG t.Run(db.Name, func(t *testing.T) { // same SQL, same assertions }) } } ``` - `testDBs(t)` returns pglike always; adds real PG when a connection string is available (e.g. `PG_TEST_DSN` env var) - CI can run pglike-only; local dev or a separate CI job adds real PG - Add compat tests incrementally when translation bugs are discovered ## Why not pgTAP - High implementation cost for a custom SQL test framework - Without `EXECUTE`, the most interesting assertions (`throws_ok`, `cmp_ok`) are impossible - Most pgTAP functions (roles, schemas, triggers) are irrelevant to pglike - Go-native dual-target tests achieve the same goal with less machinery See #2 for the original pgTAP discussion. --- *Migrated from Codeberg: originally [#5](https://codeberg.org/hum3/go-postgres/issues/5), opened 2026-03-19.*

hum3 added the

OnDemand

label

2026-08-07 14:22:10 +00:00

No labels

OnDemand

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

hum3/go-postgres#5

No description provided.

Rows
Columns