The built-in spec is a great way to get an adapter up to feature parity. We should additionally enable plugin authors to write their own integration tests that reproduce bespoke bugs, iterate over the edge cases of adapter-specific features, test custom materializations, or otherwise have too many moving pieces for python unit tests to suffice.
dbt-core and the "core four" plugins (postgres, redshift, snowflake, bigquery) all run a suite of integration tests that take test.integration.base as their starting point. The scaffolding includes the DBTIntegrationTest class, the use_profile decorator, and a few more specific helpers (FakeArgs function, AnyFloat/AnyString/etc for types).
We should move test.integration.base into this repository, expose it as a module from the pytest-dbt-adapter package, and make the main dbt repo import it as well. This would also be the first step toward truly separating out the various "core" tests by adapter.
Should we find that a core integration test has been reimplemented over and over, across many adapters, we could codify it as a new built-in sequence. That would enable a given adapter to run the test with a lot less copy-paste. By doing so, we'd also also commit to maintaining that test going forward.
Closing this, will write a new issue outlining how to easily write custom integration tests for adapters without just copying over the dbt core integration test base class :)
The built-in spec is a great way to get an adapter up to feature parity. We should additionally enable plugin authors to write their own integration tests that reproduce bespoke bugs, iterate over the edge cases of adapter-specific features, test custom materializations, or otherwise have too many moving pieces for python unit tests to suffice.
dbt-core and the "core four" plugins (postgres, redshift, snowflake, bigquery) all run a suite of integration tests that take
test.integration.base
as their starting point. The scaffolding includes theDBTIntegrationTest
class, theuse_profile
decorator, and a few more specific helpers (FakeArgs
function,AnyFloat
/AnyString
/etc for types).We should move
test.integration.base
into this repository, expose it as a module from thepytest-dbt-adapter
package, and make the main dbt repo import it as well. This would also be the first step toward truly separating out the various "core" tests by adapter.Should we find that a core integration test has been reimplemented over and over, across many adapters, we could codify it as a new built-in
sequence
. That would enable a given adapter to run the test with a lot less copy-paste. By doing so, we'd also also commit to maintaining that test going forward.