Message-ID: <gh-pgjdbc-pgjdbc-4113@github.com>
From: "vlsi (@vlsi)" <noreply+vlsi@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Tue, 26 May 2026 12:01:01 +0000
Subject: [pgjdbc/pgjdbc] PR #4113: test: make message assertions locale-independent
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Id: 213894
X-GitHub-Author-Login: vlsi
X-GitHub-Issue: 4113
X-GitHub-Labels: building-and-testing
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-State: merged
X-GitHub-Type: pull_request
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/pull/4113
Content-Type: text/plain; charset=utf-8

## What

Make exception-message assertions in four tests locale-independent. Wrap the expected text in `GT.tr(...)` so the comparison matches whatever the JVM's default locale resolves the template to.

Affected tests:

- `org.postgresql.jdbc.ScramTest`
  - `invalidPasswords`: wraps the expected text in `GT.tr(...)`.
  - `rejectIterationCountAboveDefaultCap`: drops the locale-dependent `contains("exceeds")` assertion. The remaining checks (the `scramMaxIterations` property name and the locale-formatted iteration count) already pin the test to the iteration-cap error path.
- `org.postgresql.test.jdbc2.PreparedStatementTest.testBadBoolean`: uses `GT.tr("Cannot cast to boolean: \"{0}\"", value)` for the message-with-value cases. The two `assertEquals("Cannot cast to boolean", ...)` calls stay as raw English literals because the source throws that literal without `GT.tr`.
- `org.postgresql.test.jdbc2.ResultSetTest`
  - text-mode branch of `testBadBoolean`: uses `GT.tr(...)`.
  - binary-mode branch: derives the locale-specific prefix, middle, and suffix from the `"Cannot convert the column of type {0} to requested type {1}."` template via placeholder markers, then checks the actual message lines up.
  - `testgetBoolean`: wraps the `"2"` and `"2.0"` cases in `GT.tr(...)`.
- `org.postgresql.test.jdbc2.UpdateableResultTest`: wraps the three `"No eligible primary or unique key found for table …"` asserts in `GT.tr(...)`.

## Why

The CI matrix runs jobs with `ru_RU` and other non-English locales. Production code routes the affected messages through `GT.tr` at the throw site, so the JVM picks up the localised string from the gettext catalogue. Hard-coded English assertions fail on those jobs even though the behaviour is correct.

The run that surfaced this: https://github.com/pgjdbc/pgjdbc/actions/runs/26416335971. Fourteen cases failed across the four classes above.

The `GT.tr(...)` pattern is already used in `PreparedStatementTest.checkInfinityLiterals`, so the fix follows existing precedent.

## How to verify

- Run the CI matrix with `ru_RU`; the 14 previously failing cases should pass.
- Run the CI matrix with the default English locale; `GT.tr(template, args)` returns the English template when no translation matches, so the assertions continue to pass.