Separate adapter-specific caveats for unit tests

website/docs/docs/build/unit-tests.md

@@ -24,11 +24,13 @@ Starting in dbt Core v1.8, we have introduced an additional type of test to dbt
 - We currently only support adding unit tests to models in your _current_ project.
 - We currently _don't_ support unit testing models that use the [`materialized view`](/docs/build/materializations#materialized-view) materialization.
 - We currently _don't_ support unit testing models that use recursive SQL.
-- You must specify all fields in a BigQuery STRUCT in a unit test. You cannot use only a subset of fields in a STRUCT.
 - If your model has multiple versions, by default the unit test will run on *all* versions of your model. Read [unit testing versioned models](/reference/resource-properties/unit-testing-versions) for more information.
 - Unit tests must be defined in a YML file in your `models/` directory.
 - Table names must be [aliased](/docs/build/custom-aliases) in order to unit test `join` logic.
-- Redshift customers need to be aware of a [limitation when building unit tests](/reference/resource-configs/redshift-configs#unit-test-limitations) that requires a workaround. 
+
+Adapter-specific caveats:
+- You must specify all fields in a BigQuery `STRUCT` in a unit test. You cannot use only a subset of fields in a `STRUCT`.
+- Redshift customers need to be aware of a [limitation when building unit tests](/reference/resource-configs/redshift-configs#unit-test-limitations) that requires a workaround.
 
 Read the [reference doc](/reference/resource-properties/unit-tests) for more details about formatting your unit tests.