cleanup stale test migration docs (#12274)

ARCHITECTURE.md

@@ -17,10 +17,6 @@ The main subdirectories of core/dbt:
 - [`parser`](core/dbt/parser/README.md): Read project files, validate, construct python objects
 - [`task`](core/dbt/task/README.md): Set forth the actions that dbt can perform when invoked
 
-Legacy tests are found in the 'test' directory:
-- [`unit tests`](core/dbt/test/unit/README.md): Unit tests
-- [`integration tests`](core/dbt/test/integration/README.md): Integration tests
-
 ### Invoking dbt
 
 The "tasks" map to top-level dbt commands. So `dbt run` => task.run.RunTask, etc. Some are more like abstract base classes (GraphRunnableTask, for example) but all the concrete types outside of task should map to tasks. Currently one executes at a time. The tasks kick off their “Runners” and those do execute in parallel. The parallelism is managed via a thread pool, in GraphRunnableTask.
@@ -45,7 +41,7 @@ The Postgres adapter code is the most central, and many of its implementations a
 
 ## Testing dbt
 
-The [`test/`](test/) subdirectory includes unit and integration tests that run as continuous integration checks against open pull requests. Unit tests check mock inputs and outputs of specific python functions. Integration tests perform end-to-end dbt invocations against real adapters (Postgres, Redshift, Snowflake, BigQuery) and assert that the results match expectations. See [the contributing guide](CONTRIBUTING.md) for a step-by-step walkthrough of setting up a local development and testing environment.
+The [`tests/`](tests/) subdirectory includes unit and fuctional tests that run as continuous integration checks against open pull requests. Unit tests check mock inputs and outputs of specific python functions. Functional tests perform end-to-end dbt invocations against real adapters (Postgres) and assert that the results match expectations. See [the contributing guide](CONTRIBUTING.md) for a step-by-step walkthrough of setting up a local development and testing environment.
 
 ## Everything else
 

tests/CONVERTING.md

@@ -1,37 +0,0 @@
-# Notes on converting tests from unittest to pytest
-
-* Base fixtures are provided in the core/dbt/tests/fixtures/project.py
-* You can override any fixture by specifying it in your test script
-* You can't use any test utility from the legacy tests that starts with 'self'.
-* Most special case assert functions will work with a simple 'assert'
-* Every integration test needs to use the 'project' fixture
-* Files are not copied (unless done explicitly in the test) so if you need
-  to access a local file (like seed.sql) you need to get the path from the project fixture,
-  (project.test\_data\_dir) or the 'test\_data\_dir' fixture (for specifying the location of data files.)
-* Table comparison methods have been moved to TableComparison in test/tables.py
-* Fixtures are for test setup, and are specified in the test signature. You can't call
-  fixtures in the middle of a test function.
-* Information from the fixture setup that might be needed later in the test is provided
-  by the project fixture return class (TestProjInfo)
-* Every fixture has a scope, which means that you can call it multiple times in the
-  same scope and it will return the same thing. Default scope is 'function', you can
-  also scope fixtures to 'module' and 'session'.
-* All fixtures are run before and after the test function they're attached to.
-  If you have teardown pieces in the fixture, do a 'yield' after the setup, and
-  the part after the 'yield' will be run at teardown.
-* 'run\_dbt', 'run\_sql', and 'get\_manifest' are provided by the core/dbt/tests/util.py file
-* You will probably want to make separate test files out of tests that use
-  substantially different projects. If they're only different by a file or two,
-  you could write out individual files instead and keep them in the same file.
-* You can also import file strings from other test cases
-* old: self.get\_models\_in\_schema, new: get\_tables\_in\_schema
-* somewhat easier way to get the legacy files into a more usable format:
-  ```tail -n +1 models/* > copy_models.out```
-* some of the legacy tests used a 'default_project' method to change (for example)
-  the seeds directory to load a different seed. Don't do that. Copying a file is
-  probably a better option.
-* If there are more than 50 lines of fixture strings, they should be defined in a fixtures.py and then imported. We definitely don't do this everywhere right now but should move to this model.
-
-# Integration test directories that have been converted
-* 001\_simple\_copy\_tests => moved to 'basic'
-* 003\_simple\_reference\_tests => moved to 'basic'