Setup shared tests

[mikealfare]

resolves #4

Problem

Most of the shared adapter zone integration tests were skipped since they were also executed from within the adapter zone instead of from within the functional testing directory. A handful of integration tests were implemented as expected.

Solution

• ✅ Update dbt-tests-adapter to allow all test bases to be imported (Create separate base classes for shared tests dbt-adapters#93)
• Import all base test classes and implement without alteration
• Put new tests in a directory shared_tests (open to suggestions)
• Leave tests which were already implemented in their existing spot (not in shared_tests, also open to suggestions)

Checklist

• I have read the contributing guide and understand what's expected of me
• I have run this code in development and it appears to resolve the stated issue
• This PR includes tests, or tests are not required/relevant for this PR
• This PR has no interface changes (e.g. macros, cli, logs, json artifacts, config files, adapter interface, etc) or this PR has already received feedback and approval from Product or DX

[VersusFacit]

Oh boy oh boy, add 'em up.

What was your criteria for core? Basically just listed out the files and imported all the classes that way? Just curious how we can keep ourselves honest here tracking wise and avoid missing any.

I did a simple ag "class Base" (`grep -r . "class Base" or what have you) to highlight all the tests that should end up in this PR, you'd think.

Also, anything out of core's dbt-core/tests/adapter/setup.py we want to import over to conftest or some such?

[mikealfare]

What was your criteria for core? Basically just listed out the files and imported all the classes that way?

That's correct. I made it one to one between the directory in dbt-tests-adapter and the module in dbt-postgres. For example, dbt-tests-adapter has a directory for basic that contains several test modules. I created a single test module test_basic in dbt-postgres that imported from all of those modules. There were a few scenarios where the tests were already implemented. For example, materialized view tests were implemented in this way in dbt-core. So when the tests were moved from tests/functional in dbt-core to dbt-postgres, they came along for the ride. That's why you'll notice this module is missing from shared_tests.

Just curious how we can keep ourselves honest here tracking wise and avoid missing any.

I don't have a good way to do this, without perhaps running tests on dbt-core==1.7, taking note of what the collector collects, and then comparing that. And then this immediately deviates once we start writing new tests.

I did a simple ag "class Base" (`grep -r . "class Base" or what have you) to highlight all the tests that should end up in this PR, you'd think.

Were you able to find any that I missed?

Also, anything out of core's dbt-core/tests/adapter/setup.py we want to import over to conftest or some such?

This no longer exists, it was moved as part of dbt-tests-adapter and is now pyproject.toml. The fixtures were imported as a pytest plugin (the way we do in other adapters).

[VersusFacit]

I wrote a script to help with this. I grabbed all Base test names out of core:

class_names_file="classes.txt" # I just sliced out all tests using vim real quick
python_files_directory="./dbt-postgres/tests" # on your branch

# Check each class name in the class names file
while IFS= read -r class_name; do
    found=0
    if grep -q -r "\($class_name\)" "$python_files_directory" ; then
      found=1
    fi
    # If the class name was not found in any file
    if [ $found -eq 0 ]; then
        echo "Class $class_name not found in any Python file."
    fi
done < "$class_names_file"

Class BasePythonIncrementalTests not found in any Python file.
Class BaseSimpleSnapshotBase not found in any Python file.
Class BaseGrants not found in any Python file.
Class BasePersistDocsBase not found in any Python file.
Class BaseIncrementalOnSchemaChangeSetup not found in any Python file.
Class BaseCachingTest not found in any Python file.
Class BaseUtils not found in any Python file.
Class BaseGenerateProject not found in any Python file.
Class BaseContractSqlHeader not found in any Python file.
Class BaseConstraintsColumnsEqual not found in any Python file.
Class BaseDataTypeMacro not found in any Python file.
Class BasePythonModelTests not found in any Python file.
Class BaseArrayUtils not found in any Python file.
Class BaseCurrentTimestampNaive not found in any Python file.
Class BasePySparkTests not found in any Python file.
Class BaseTestPrePost not found in any Python file.
Class BaseDefaultQueryComments not found in any Python file.

[mikealfare]

Thanks, that provides a good way to verify that we have imported all tests where appropriate. I went through the base classes you turned up and accounted for why they are excluded. They fall into three catagories.

Base classes with no test methods:

• BaseDefaultQueryComments
• BaseGenerateProject
• BaseGrants
• BaseIncrementalOnSchemaChangeSetup
• BasePersistDocsBase
• BaseSimpleSnapshotBase
• BaseTestPrePost

Base classes with test methods that assume configuration in inherited test classes (should not be run directly):

• BaseArrayUtils
• BaseCachingTest
• BaseConstraintsColumnsEqual
• BaseContractSqlHeader
• BaseDataTypeMacro
• BaseUtils

Functionality does not apply to Postgres:

• BaseCurrentTimestampNaive - Postgres is aware, hence uses BaseCurrentTimestampAware
• BasePythonIncrementalTests - there are no python models in Postgres
• BasePythonModelTests
• BasePySparkTests

This means that we imported all tests that apply to dbt-postgres.