From 15799bde51932b1d2af4a4f1d45ee30360dc403f Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Thu, 17 Oct 2024 19:42:41 -0400
Subject: [PATCH 01/15] Adjust instructions for running EF integration tests

---
 .../server/database/ef/index.mdx              | 72 ++++++++++++-------
 1 file changed, 45 insertions(+), 27 deletions(-)

diff --git a/docs/getting-started/server/database/ef/index.mdx b/docs/getting-started/server/database/ef/index.mdx
index 1e41894ed..e1965bca2 100644
--- a/docs/getting-started/server/database/ef/index.mdx
+++ b/docs/getting-started/server/database/ef/index.mdx
@@ -196,30 +196,48 @@ If you would like to verify that everything worked correctly:
 
 ## Testing EF Changes
 
-Since we allow for multiple databases it is important that any changes to EF repositories/models are
-tested against all possible databases. You may want to use a database that is different from your
-local development database because the tests may add or remove data. To apply migrations to a
-database different from your global settings run the following commands from the root of your
-repository
-
-```bash
-# EntityFramework CLI Reference: https://learn.microsoft.com/en-us/ef/core/cli/dotnet
-
-# Migrate Postgres database ex connection string: Host=localhost;Username=postgres;Password=SET_A_PASSWORD_HERE_123;Database=vault_dev_test
-dotnet ef database update --startup-project util/PostgresMigrations --connection "[POSTGRES_CONNECTION_STRING]"
-
-# Migrate MySql database ex connection string: server=localhost;uid=root;pwd=SET_A_PASSWORD_HERE_123;database=vault_dev_test
-dotnet ef database update --startup-project util/MySqlMigrations --connection "[MYSQL_CONNECTION_STRING]"
-
-cd test/Infrastructure.IntegrationTest
-
-# https://learn.microsoft.com/en-us/aspnet/core/security/app-secrets?view=aspnetcore-6.0&tabs=windows#secret-manager
-dotnet user-secrets set "Ef:Postgres" "[POSTGRES_CONNECTION_STRING]"
-dotnet user-secrets set "Ef:MySql" "[MYSQL_CONNECTION_STRING]"
-
-# You can also set the connection string for your normal development MS SQL database like below
-dotnet user-secrets set "Dapper:SqlServer" "[MSSQL_CONNECTION_STRING]"
-```
-
-You can then run just those tests from the `test/Infrastructure.IntegrationTest` folder using
-`dotnet test`.
+In your `server/dev/secrets.json` file find these two blocks of secrets:
+
+- This block is used for your primary Bitwarden database for each supported provider type. These are
+  what your running development server will connect to. You should already have passwords set up in
+  this block.
+  - If you do: ensure the username/password combos for each of your global database types are
+    applied to their siblings in the `databases` block.
+  - If you do not: please see the user secrets section of the server setup guide for doing this.
+  ```
+  "sqlServer": {
+    "connectionString": "Server=localhost;Database=vault_dev;User Id=SA;Password=___________;Encrypt=True;TrustServerCertificate=True;"
+  },
+  "postgreSql": {
+    "connectionString": "Host=localhost;Username=postgres;Password=_________;Database=vault_dev"
+  },
+  "mySql": {
+    "connectionString": "server=localhost;uid=root;pwd=_________;database=vault_dev"
+  },
+  "sqlite": {
+    "connectionString": "Data Source=/path/to/bitwardenServer/repository/server/dev/db/bitwarden.sqlite"
+  },
+  ```
+- This block is used for test databases for each supported provider type. These are what integration
+  tests will connect to. You should update the password for these connection strings to match your
+  existing databases if you have not already. If these settings are not present at all in your
+  `secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
+  Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
+  ```
+  "databases:0:type": "Postgres",
+  "databases:0:connectionString": "Host=localhost;Username=postgres;Password=_________;Database=ef_test",
+  "databases:0:enabled": "true",
+  "databases:1:type": "Sqlite",
+  "databases:1:enabled": "true",
+  "databases:1:connectionString": "Data Source=_________",
+  "databases:2:type": "MySql",
+  "databases:2:connectionString": "server=localhost;uid=root;pwd=_________;database=ef_test",
+  "databases:2:enabled": "true",
+  "databases:3:type": "SqlServer",
+  "databases:3:connectionString": "Server=localhost;Database=ef_test;User Id=SA;Password=_________;Encrypt=True;TrustServerCertificate=True;",
+  "databases:3:enabled": "true"
+  ```
+
+With connection strings applied to your projects: ensure your databases are all migrated using
+`pwsh server/dev/migrate.ps1 --all`. Then you can run EF tests from the
+`test/Infrastructure.IntegrationTest` folder using `dotnet test`.

From 3d7bab247004bdaaa33ba20d8019d2f6f14ccb7b Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Thu, 16 Jan 2025 13:35:39 -0500
Subject: [PATCH 02/15] Removed first section & callout hardcoded indexes

---
 .../server/database/ef/index.mdx              | 71 ++++++++-----------
 1 file changed, 30 insertions(+), 41 deletions(-)

diff --git a/docs/getting-started/server/database/ef/index.mdx b/docs/getting-started/server/database/ef/index.mdx
index e1965bca2..32b8c82ae 100644
--- a/docs/getting-started/server/database/ef/index.mdx
+++ b/docs/getting-started/server/database/ef/index.mdx
@@ -196,47 +196,36 @@ If you would like to verify that everything worked correctly:
 
 ## Testing EF Changes
 
-In your `server/dev/secrets.json` file find these two blocks of secrets:
-
-- This block is used for your primary Bitwarden database for each supported provider type. These are
-  what your running development server will connect to. You should already have passwords set up in
-  this block.
-  - If you do: ensure the username/password combos for each of your global database types are
-    applied to their siblings in the `databases` block.
-  - If you do not: please see the user secrets section of the server setup guide for doing this.
-  ```
-  "sqlServer": {
-    "connectionString": "Server=localhost;Database=vault_dev;User Id=SA;Password=___________;Encrypt=True;TrustServerCertificate=True;"
-  },
-  "postgreSql": {
-    "connectionString": "Host=localhost;Username=postgres;Password=_________;Database=vault_dev"
-  },
-  "mySql": {
-    "connectionString": "server=localhost;uid=root;pwd=_________;database=vault_dev"
-  },
-  "sqlite": {
-    "connectionString": "Data Source=/path/to/bitwardenServer/repository/server/dev/db/bitwarden.sqlite"
-  },
-  ```
-- This block is used for test databases for each supported provider type. These are what integration
-  tests will connect to. You should update the password for these connection strings to match your
-  existing databases if you have not already. If these settings are not present at all in your
-  `secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
-  Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
-  ```
-  "databases:0:type": "Postgres",
-  "databases:0:connectionString": "Host=localhost;Username=postgres;Password=_________;Database=ef_test",
-  "databases:0:enabled": "true",
-  "databases:1:type": "Sqlite",
-  "databases:1:enabled": "true",
-  "databases:1:connectionString": "Data Source=_________",
-  "databases:2:type": "MySql",
-  "databases:2:connectionString": "server=localhost;uid=root;pwd=_________;database=ef_test",
-  "databases:2:enabled": "true",
-  "databases:3:type": "SqlServer",
-  "databases:3:connectionString": "Server=localhost;Database=ef_test;User Id=SA;Password=_________;Encrypt=True;TrustServerCertificate=True;",
-  "databases:3:enabled": "true"
-  ```
+In your `server/dev/secrets.json` file find or add this block of secrets in the root of the json structure:
+
+```
+"databases:0:type": "Postgres",
+"databases:0:connectionString": "Host=localhost;Username=postgres;Password=_________;Database=ef_test",
+"databases:0:enabled": "true",
+"databases:1:type": "Sqlite",
+"databases:1:enabled": "true",
+"databases:1:connectionString": "Data Source=_________",
+"databases:2:type": "MySql",
+"databases:2:connectionString": "server=localhost;uid=root;pwd=_________;database=ef_test",
+"databases:2:enabled": "true",
+"databases:3:type": "SqlServer",
+"databases:3:connectionString": "Server=localhost;Database=ef_test;User Id=SA;Password=_________;Encrypt=True;TrustServerCertificate=True;",
+"databases:3:enabled": "true"
+```
+
+:::info
+
+The example database indexe + type combinations are required for the tooling
+to work, and to support multiple versions of the same database running tests
+at the same time.
+
+:::
+
+This block is used for test databases for each supported provider type. These are what integration
+tests will connect to. You should update the password for these connection strings to match your
+existing databases if you have not already. If these settings are not present at all in your
+`secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
+Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
 
 With connection strings applied to your projects: ensure your databases are all migrated using
 `pwsh server/dev/migrate.ps1 --all`. Then you can run EF tests from the

From 4471f747ac1b4dd19be1177f96105c08bca157b4 Mon Sep 17 00:00:00 2001
From: Justin Baur <19896123+justindbaur@users.noreply.github.com>
Date: Tue, 24 Sep 2024 16:39:59 -0400
Subject: [PATCH 03/15] Initial Database Testing Document

---
 docs/contributing/testing/database/index.md | 93 +++++++++++++++++++++
 1 file changed, 93 insertions(+)
 create mode 100644 docs/contributing/testing/database/index.md

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
new file mode 100644
index 000000000..0f78cf802
--- /dev/null
+++ b/docs/contributing/testing/database/index.md
@@ -0,0 +1,93 @@
+# Database Integration Testing
+
+Since Bitwarden has multiple database options, testing them all automatically is incredibly
+important so that we don't have to have a full QA process for each database type. This is where the
+`Infrastructure.IntegrationTest` project comes in, allowing the setup of tests similarly to how the
+databases are consumed in the applications through their common interfaces, generally an
+`I*Repository`. These tests are automatically executed on all supported databases in our testing
+pipeline.
+
+## Creating a new test
+
+To create a new database test just add the `[DatabaseTheory]` and `[DatabaseData]` attributes to
+test. Now, in the parameters of the test you are able to "inject" any repository layer services
+directly into the test. The test will run for every database that is
+[configured in the current environment](#configure-the-tests). Since you inject the interface of the
+service, some runs of the test will use the Dapper based repository implementation targeting
+Microsoft SQL Server and others will use the Entity Framework Core based implementations, which we
+use for MySql, Postgres, and SQLite.
+
+The goal of database tests is to test the business logic that is encapsulated in a given method. If
+the stored procedure in SQL Server then calls another procedure to update the
+`User.AccountRevisionDate` then the same EF implementation should do that as well. By running the
+test against all variants we are ensuring all the variants are feature-equal. Locally, you may want
+to only run the SQL Server tests along with one EF implementation; SQLite is often the easiest in
+that situation. This may work well for a very long time and save you some time overall but there are
+differences between the EF database providers such that you will one day get errors in the CI
+pipeline.
+
+## Configure the databases
+
+The databases are expected to have the latest migrations applied.
+
+## Configure the tests
+
+The tests are configured through
+[.NET Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration) in the
+order they are applied: user secrets, environment variables prefixed with `BW_TEST_`, and command
+line args.
+
+```csharp
+public class Root
+{
+    public Database[] Databases { get; set; }
+}
+
+public class Database
+{
+    public SupportedDatabaseProviders Type { get; set; }
+    public string ConnectionString { get; set; } = default!;
+    public bool UseEf { get; set; }
+    public bool Enabled { get; set; } = true;
+}
+```
+
+The `Type` property is an enum with the supported values being `SqlServer`, `MySql`, `Postgres`, or
+`Sqlite`. The `UseEf` property is only utilized if the `Type` is set to `SqlServer`; by default
+`SqlServer` will be configured with the Dapper repositories, however by setting `UseEf` to `true` it
+will be configured with the Entity Framework Core repositories. `Enabled` allows you to easily
+disable one database but not delete the entry; it can be helpful if you are encountering a problem
+with just a single database type and want to run the tests just for it instead of for all of them.
+
+### Locally
+
+To set the tests up locally you may want to add the configuration to your `dev/secrets.json` file.
+An example entry you might add is:
+
+```json
+{
+  ...other config...
+  "databases": [
+    {
+      "type": "SqlServer",
+      "connectionString": "myConnectionString"
+    }
+  ]
+}
+```
+
+You can also configure the tests just like the pipeline.
+
+### Pipeline
+
+The database tests have been pre-configured to run on all supported databases in the
+[`test-database.yml`](https://github.com/bitwarden/server/blob/main/.github/workflows/test-database.yml)
+([permalink](https://github.com/bitwarden/server/blob/f7bc5dfb2ea31ca7b4c36238295cdcc4008ad958/.github/workflows/test-database.yml))
+file.
+
+The pipeline uses environment variables. An example entry you might add is:
+
+```bash
+BW_TEST_DATABASES__0__TYPE: SqlServer
+BW_TEST_DATABASES__0__CONNECTIONSTRING: myConnectionString
+```

From 19ce5aafc712287759de58aa12eba616ad9a8cfb Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Thu, 16 Jan 2025 13:59:32 -0500
Subject: [PATCH 04/15] Link to getting-started guide for instructions on
 running tests locally

---
 docs/contributing/testing/database/index.md | 16 +++-------------
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 0f78cf802..5c258bf3d 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -62,19 +62,9 @@ with just a single database type and want to run the tests just for it instead o
 ### Locally
 
 To set the tests up locally you may want to add the configuration to your `dev/secrets.json` file.
-An example entry you might add is:
-
-```json
-{
-  ...other config...
-  "databases": [
-    {
-      "type": "SqlServer",
-      "connectionString": "myConnectionString"
-    }
-  ]
-}
-```
+You may have already done this during setup and can just run the tests with `dotnet test`. If not,
+please refer to
+[the getting started guide](/getting-started/server/database/ef/#testing-ef-changes).
 
 You can also configure the tests just like the pipeline.
 

From bbb8ecaac82ab99531d8df0118b17fdedfbd64aa Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Thu, 16 Jan 2025 14:01:52 -0500
Subject: [PATCH 05/15] Ran prettier

---
 docs/getting-started/server/database/ef/index.mdx | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/getting-started/server/database/ef/index.mdx b/docs/getting-started/server/database/ef/index.mdx
index 32b8c82ae..d4e0b91ec 100644
--- a/docs/getting-started/server/database/ef/index.mdx
+++ b/docs/getting-started/server/database/ef/index.mdx
@@ -196,7 +196,8 @@ If you would like to verify that everything worked correctly:
 
 ## Testing EF Changes
 
-In your `server/dev/secrets.json` file find or add this block of secrets in the root of the json structure:
+In your `server/dev/secrets.json` file find or add this block of secrets in the root of the json
+structure:
 
 ```
 "databases:0:type": "Postgres",
@@ -215,9 +216,8 @@ In your `server/dev/secrets.json` file find or add this block of secrets in the
 
 :::info
 
-The example database indexe + type combinations are required for the tooling
-to work, and to support multiple versions of the same database running tests
-at the same time.
+The example database index + type combinations are required for the tooling to work, and to support
+multiple versions of the same database running tests at the same time.
 
 :::
 

From 64969e938af68113efe44a7b7f39010147afe74a Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Tue, 21 Jan 2025 15:45:48 -0500
Subject: [PATCH 06/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Maciej Zieniuk <167752252+mzieniukbw@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 5c258bf3d..92506a804 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -61,7 +61,7 @@ with just a single database type and want to run the tests just for it instead o
 
 ### Locally
 
-To set the tests up locally you may want to add the configuration to your `dev/secrets.json` file.
+To set the tests up locally you may want to add the configuration to your `server/dev/secrets.json` file.
 You may have already done this during setup and can just run the tests with `dotnet test`. If not,
 please refer to
 [the getting started guide](/getting-started/server/database/ef/#testing-ef-changes).

From de466203ec1e17c89e71a505c239b0b0a2220e0f Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Tue, 21 Jan 2025 15:46:00 -0500
Subject: [PATCH 07/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Maciej Zieniuk <167752252+mzieniukbw@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 1 -
 1 file changed, 1 deletion(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 92506a804..4b20759da 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -72,7 +72,6 @@ You can also configure the tests just like the pipeline.
 
 The database tests have been pre-configured to run on all supported databases in the
 [`test-database.yml`](https://github.com/bitwarden/server/blob/main/.github/workflows/test-database.yml)
-([permalink](https://github.com/bitwarden/server/blob/f7bc5dfb2ea31ca7b4c36238295cdcc4008ad958/.github/workflows/test-database.yml))
 file.
 
 The pipeline uses environment variables. An example entry you might add is:

From 6b57b3379e2e900ede1af2bcceb594f849f9a6b4 Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Tue, 21 Jan 2025 15:48:51 -0500
Subject: [PATCH 08/15] Update
 docs/getting-started/server/database/ef/index.mdx

---
 docs/getting-started/server/database/ef/index.mdx | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/getting-started/server/database/ef/index.mdx b/docs/getting-started/server/database/ef/index.mdx
index d4e0b91ec..4b761a818 100644
--- a/docs/getting-started/server/database/ef/index.mdx
+++ b/docs/getting-started/server/database/ef/index.mdx
@@ -224,7 +224,7 @@ multiple versions of the same database running tests at the same time.
 This block is used for test databases for each supported provider type. These are what integration
 tests will connect to. You should update the password for these connection strings to match your
 existing databases if you have not already. If these settings are not present at all in your
-`secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
+`server/dev/secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
 Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
 
 With connection strings applied to your projects: ensure your databases are all migrated using

From 9d9467633793c753290fe8ac0b07fb18e6ba66ba Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Tue, 21 Jan 2025 15:49:47 -0500
Subject: [PATCH 09/15] Ran prettier

---
 docs/contributing/testing/database/index.md       | 6 +++---
 docs/getting-started/server/database/ef/index.mdx | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 4b20759da..7777d1e16 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -61,9 +61,9 @@ with just a single database type and want to run the tests just for it instead o
 
 ### Locally
 
-To set the tests up locally you may want to add the configuration to your `server/dev/secrets.json` file.
-You may have already done this during setup and can just run the tests with `dotnet test`. If not,
-please refer to
+To set the tests up locally you may want to add the configuration to your `server/dev/secrets.json`
+file. You may have already done this during setup and can just run the tests with `dotnet test`. If
+not, please refer to
 [the getting started guide](/getting-started/server/database/ef/#testing-ef-changes).
 
 You can also configure the tests just like the pipeline.
diff --git a/docs/getting-started/server/database/ef/index.mdx b/docs/getting-started/server/database/ef/index.mdx
index 4b761a818..c4ebd649b 100644
--- a/docs/getting-started/server/database/ef/index.mdx
+++ b/docs/getting-started/server/database/ef/index.mdx
@@ -224,8 +224,8 @@ multiple versions of the same database running tests at the same time.
 This block is used for test databases for each supported provider type. These are what integration
 tests will connect to. You should update the password for these connection strings to match your
 existing databases if you have not already. If these settings are not present at all in your
-`server/dev/secrets.json` file just add them to the bottom. These settings _do not_ go in `globalSettings`.
-Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
+`server/dev/secrets.json` file just add them to the bottom. These settings _do not_ go in
+`globalSettings`. Then run `pwsh setup_secrets.ps1 -clear` to apply them to your local projects.
 
 With connection strings applied to your projects: ensure your databases are all migrated using
 `pwsh server/dev/migrate.ps1 --all`. Then you can run EF tests from the

From e51bb999babc69dc824d28da6d15b7dbff1be55d Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:42:20 -0500
Subject: [PATCH 10/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Thomas Rittson <31796059+eliykat@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 7777d1e16..80e7b76a6 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -1,11 +1,6 @@
 # Database Integration Testing
 
-Since Bitwarden has multiple database options, testing them all automatically is incredibly
-important so that we don't have to have a full QA process for each database type. This is where the
-`Infrastructure.IntegrationTest` project comes in, allowing the setup of tests similarly to how the
-databases are consumed in the applications through their common interfaces, generally an
-`I*Repository`. These tests are automatically executed on all supported databases in our testing
-pipeline.
+Since Bitwarden has multiple database options, automated testing is extremely important to avoid time-consuming manual testing for each database type. The `Infrastructure.IntegrationTest` project allows you to write tests that are automatically executed on all supported databases in our testing pipeline.
 
 ## Creating a new test
 

From 7e6cb69ce2ac67b4567fa9b2831fe4817b76fcb3 Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:43:11 -0500
Subject: [PATCH 11/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Thomas Rittson <31796059+eliykat@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 80e7b76a6..89aba4b60 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -4,13 +4,13 @@ Since Bitwarden has multiple database options, automated testing is extremely im
 
 ## Creating a new test
 
-To create a new database test just add the `[DatabaseTheory]` and `[DatabaseData]` attributes to
-test. Now, in the parameters of the test you are able to "inject" any repository layer services
-directly into the test. The test will run for every database that is
+To create a new database test, add the `[DatabaseTheory]` and `[DatabaseData]` attributes to
+test. Then, use the parameters of the test to inject any repository layer services
+you need. The test will run for every database that is
 [configured in the current environment](#configure-the-tests). Since you inject the interface of the
-service, some runs of the test will use the Dapper based repository implementation targeting
-Microsoft SQL Server and others will use the Entity Framework Core based implementations, which we
-use for MySql, Postgres, and SQLite.
+service, some runs of the test will use the Dapper-based repository implementation targeting
+Microsoft SQL Server and others will use the Entity Framework Core based implementations (which we
+use for MySql, Postgres, and SQLite).
 
 The goal of database tests is to test the business logic that is encapsulated in a given method. If
 the stored procedure in SQL Server then calls another procedure to update the

From 54008da0d54975656cb4dca829fc0a0917303132 Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:43:28 -0500
Subject: [PATCH 12/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Thomas Rittson <31796059+eliykat@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 89aba4b60..a90da37e4 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -12,10 +12,10 @@ service, some runs of the test will use the Dapper-based repository implementati
 Microsoft SQL Server and others will use the Entity Framework Core based implementations (which we
 use for MySql, Postgres, and SQLite).
 
-The goal of database tests is to test the business logic that is encapsulated in a given method. If
-the stored procedure in SQL Server then calls another procedure to update the
-`User.AccountRevisionDate` then the same EF implementation should do that as well. By running the
-test against all variants we are ensuring all the variants are feature-equal. Locally, you may want
+The goal of database tests is to test the business logic that is encapsulated in a given method. For example, if
+a stored procedure in SQL Server calls another procedure to update the
+`User.AccountRevisionDate` then the corresponding EF implementation should do that as well. By running the
+test against all variants, we are ensuring all the variants are feature-equal.
 to only run the SQL Server tests along with one EF implementation; SQLite is often the easiest in
 that situation. This may work well for a very long time and save you some time overall but there are
 differences between the EF database providers such that you will one day get errors in the CI

From e52e153bba0c485b602881753edc64d4b85ee993 Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:43:41 -0500
Subject: [PATCH 13/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Thomas Rittson <31796059+eliykat@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index a90da37e4..625f17437 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -28,8 +28,7 @@ The databases are expected to have the latest migrations applied.
 ## Configure the tests
 
 The tests are configured through
-[.NET Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration) in the
-order they are applied: user secrets, environment variables prefixed with `BW_TEST_`, and command
+[.NET Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration). They are applied in the following order: user secrets, environment variables prefixed with `BW_TEST_`, and command
 line args.
 
 ```csharp

From 25132b91280ae6ac1dabc19479d422e85628e922 Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:44:02 -0500
Subject: [PATCH 14/15] Update docs/contributing/testing/database/index.md

Co-authored-by: Thomas Rittson <31796059+eliykat@users.noreply.github.com>
---
 docs/contributing/testing/database/index.md | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index 625f17437..f84f9e9b4 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -17,9 +17,8 @@ a stored procedure in SQL Server calls another procedure to update the
 `User.AccountRevisionDate` then the corresponding EF implementation should do that as well. By running the
 test against all variants, we are ensuring all the variants are feature-equal.
 to only run the SQL Server tests along with one EF implementation; SQLite is often the easiest in
-that situation. This may work well for a very long time and save you some time overall but there are
-differences between the EF database providers such that you will one day get errors in the CI
-pipeline.
+that regard. The other supported EF database providers will still run in the pipeline to catch any
+differences between them.
 
 ## Configure the databases
 

From df4242ddfc1bbba9f342c6e86ab03021c6cb836a Mon Sep 17 00:00:00 2001
From: Addison Beck <github@addisonbeck.com>
Date: Wed, 22 Jan 2025 11:46:02 -0500
Subject: [PATCH 15/15] Remove "Configuring the database"

---
 docs/contributing/testing/database/index.md | 41 ++++++++++-----------
 1 file changed, 20 insertions(+), 21 deletions(-)

diff --git a/docs/contributing/testing/database/index.md b/docs/contributing/testing/database/index.md
index f84f9e9b4..d6a7759d6 100644
--- a/docs/contributing/testing/database/index.md
+++ b/docs/contributing/testing/database/index.md
@@ -1,34 +1,33 @@
 # Database Integration Testing
 
-Since Bitwarden has multiple database options, automated testing is extremely important to avoid time-consuming manual testing for each database type. The `Infrastructure.IntegrationTest` project allows you to write tests that are automatically executed on all supported databases in our testing pipeline.
+Since Bitwarden has multiple database options, automated testing is extremely important to avoid
+time-consuming manual testing for each database type. The `Infrastructure.IntegrationTest` project
+allows you to write tests that are automatically executed on all supported databases in our testing
+pipeline.
 
 ## Creating a new test
 
-To create a new database test, add the `[DatabaseTheory]` and `[DatabaseData]` attributes to
-test. Then, use the parameters of the test to inject any repository layer services
-you need. The test will run for every database that is
-[configured in the current environment](#configure-the-tests). Since you inject the interface of the
-service, some runs of the test will use the Dapper-based repository implementation targeting
-Microsoft SQL Server and others will use the Entity Framework Core based implementations (which we
-use for MySql, Postgres, and SQLite).
-
-The goal of database tests is to test the business logic that is encapsulated in a given method. For example, if
-a stored procedure in SQL Server calls another procedure to update the
-`User.AccountRevisionDate` then the corresponding EF implementation should do that as well. By running the
-test against all variants, we are ensuring all the variants are feature-equal.
-to only run the SQL Server tests along with one EF implementation; SQLite is often the easiest in
-that regard. The other supported EF database providers will still run in the pipeline to catch any
+To create a new database test, add the `[DatabaseTheory]` and `[DatabaseData]` attributes to test.
+Then, use the parameters of the test to inject any repository layer services you need. The test will
+run for every database that is [configured in the current environment](#configure-the-tests). Since
+you inject the interface of the service, some runs of the test will use the Dapper-based repository
+implementation targeting Microsoft SQL Server and others will use the Entity Framework Core based
+implementations (which we use for MySql, Postgres, and SQLite).
+
+The goal of database tests is to test the business logic that is encapsulated in a given method. For
+example, if a stored procedure in SQL Server calls another procedure to update the
+`User.AccountRevisionDate` then the corresponding EF implementation should do that as well. By
+running the test against all variants, we are ensuring all the variants are feature-equal. to only
+run the SQL Server tests along with one EF implementation; SQLite is often the easiest in that
+regard. The other supported EF database providers will still run in the pipeline to catch any
 differences between them.
 
-## Configure the databases
-
-The databases are expected to have the latest migrations applied.
-
 ## Configure the tests
 
 The tests are configured through
-[.NET Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration). They are applied in the following order: user secrets, environment variables prefixed with `BW_TEST_`, and command
-line args.
+[.NET Configuration](https://learn.microsoft.com/en-us/dotnet/core/extensions/configuration). They
+are applied in the following order: user secrets, environment variables prefixed with `BW_TEST_`,
+and command line args.
 
 ```csharp
 public class Root