From 21de00b097187d1e4e479ea877df64bee22b60c9 Mon Sep 17 00:00:00 2001 From: Jacob Walls Date: Wed, 6 May 2026 14:03:45 -0400 Subject: Refs #36620 -- Mentioned coverage workflow uses PostgreSQL. Before c507aaf9abeff4b93b7f9bdbc55801f2ccfc2d01, this workflow used to run on SQLite. --- docs/internals/contributing/writing-code/unit-tests.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'docs/internals/contributing/writing-code') diff --git a/docs/internals/contributing/writing-code/unit-tests.txt b/docs/internals/contributing/writing-code/unit-tests.txt index 657027a033..d19616e323 100644 --- a/docs/internals/contributing/writing-code/unit-tests.txt +++ b/docs/internals/contributing/writing-code/unit-tests.txt @@ -419,14 +419,14 @@ the lines that were changed or added in the PR. It shows: When reviewing coverage reports on pull requests, keep these limitations in mind: -* **Database-specific code:** The CI coverage job runs tests using SQLite on - Windows. Code paths specific to other databases (PostgreSQL, MySQL, Oracle) +* **Database-specific code:** The CI coverage job runs tests using PostgreSQL + on Ubuntu. Code paths specific to other databases (SQLite, MySQL, Oracle) will appear as "not covered" even if database-specific tests exist. This is expected and acceptable. * **Platform-specific code:** Similarly, code that only runs on certain - operating systems (Linux, macOS) will appear as not covered when run on - Windows. + operating systems (Windows, macOS) will appear as not covered when run on + Ubuntu. * **Coverage doesn't equal quality:** A line being "covered" only means it was executed during tests. It doesn't guarantee the line is well-tested or that -- cgit v1.3