From 7d71cdff3f75f42cab1c4b203985a4bfdcabfe08 Mon Sep 17 00:00:00 2001 From: jjpinto Date: Sat, 27 Dec 2025 10:18:48 -0500 Subject: [PATCH 1/2] Removed extra word in test-table.md --- src/test-table.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/test-table.md b/src/test-table.md index cd1ee58..6847225 100644 --- a/src/test-table.md +++ b/src/test-table.md @@ -4,7 +4,7 @@ Table-driven tests with [subtests] can be a helpful pattern for writing tests to avoid duplicating code when the core test logic is repetitive. If a system under test needs to be tested against _multiple conditions_ where -certain parts of the the inputs and outputs change, a table-driven test should +certain parts of the inputs and outputs change, a table-driven test should be used to reduce redundancy and improve readability. [subtests]: https://go.dev/blog/subtests From 05574aa942f67fa29fee0341b838879d83159ab3 Mon Sep 17 00:00:00 2001 From: jjpinto <16046674+jjpinto@users.noreply.github.com> Date: Sat, 27 Dec 2025 15:19:15 +0000 Subject: [PATCH 2/2] Auto-update style.md --- style.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/style.md b/style.md index b5c9610..9fef812 100644 --- a/style.md +++ b/style.md @@ -3663,7 +3663,7 @@ Table-driven tests with [subtests](https://go.dev/blog/subtests) can be a helpfu to avoid duplicating code when the core test logic is repetitive. If a system under test needs to be tested against *multiple conditions* where -certain parts of the the inputs and outputs change, a table-driven test should +certain parts of the inputs and outputs change, a table-driven test should be used to reduce redundancy and improve readability.