diff --git a/placement/tests/README.rst b/placement/tests/README.rst
new file mode 100644
index 000000000..6f226c6e4
--- /dev/null
+++ b/placement/tests/README.rst
@@ -0,0 +1,55 @@
+==========================================
+OpenStack Placement Testing Infrastructure
+==========================================
+
+This README file attempts to provides some brief guidance for writing tests
+when fixing bugs or adding features to placement.
+
+For a lot more information see the `contributor docs`_.
+
+Test Types: Unit vs. Functional vs. Integration
+-----------------------------------------------
+
+Placement tests are divided into three types:
+
+* Unit: tests which confirm the behavior of individual pieces of the code
+  (individual methods or classes) with minimal dependency on other code or on
+  externals like the database.
+* Functional: tests which confirm a chunk of behavior, end to end, such as an
+  HTTP endpoint accepting a body from a request and returning the expected
+  response but without reliance on code or services that are external to
+  placement.
+* Integration: tests that confirm that things work with other services, such
+  as nova.
+
+Placement uses all three, but the majority are functional tests. This is the
+result of the fairly direct architecture of placement: It is a WSGI application
+that talks to a database.
+
+Writing Unit Tests
+------------------
+
+Placement unit tests are based on the ``TestCase`` that comes with the
+``testtools`` package. Use mocks only as necessary. If you find that you need
+multiple mocks to make a test for the code you are testing may benefit from
+being refactored to smaller units.
+
+Writing Functional Tests
+------------------------
+
+There are two primary classes of functional test in placement:
+
+* Testing database operations. These are based on
+  ``placement.tests.functional.base.TestCase`` which is responsible for
+  starting an in-memory database and a reasonable minimal configuration.
+* Testing the HTTP API using `gabbi`_.
+
+Writing Integration Tests
+-------------------------
+
+Placement configures its gate and check jobs via the ``.zuul.yaml`` file in the
+root of the code repository. Some of the entries in that file configure
+integration jobs, many of which use tempest.
+
+.. _gabbi: https://gabbi.readthedocs.io/
+.. _contributor docs: https://docs.openstack.org/placement/latest/contributor/
diff --git a/placement/tests/unit/README.rst b/placement/tests/unit/README.rst
deleted file mode 100644
index 8ac999c74..000000000
--- a/placement/tests/unit/README.rst
+++ /dev/null
@@ -1,95 +0,0 @@
-=====================================
-OpenStack Nova Testing Infrastructure
-=====================================
-
-This README file attempts to provide current and prospective contributors with
-everything they need to know in order to start creating unit tests for nova.
-
-Note: the content for the rest of this file will be added as the work items in
-the following blueprint are completed:
-  https://blueprints.launchpad.net/nova/+spec/consolidate-testing-infrastructure
-
-
-Test Types: Unit vs. Functional vs. Integration
------------------------------------------------
-
-TBD
-
-Writing Unit Tests
-------------------
-
-TBD
-
-Using Fakes
-~~~~~~~~~~~
-
-TBD
-
-test.TestCase
--------------
-The TestCase class from nova.test (generally imported as test) will
-automatically manage self.stubs using the stubout module and self.mox
-using the mox module during the setUp step. They will automatically
-verify and clean up during the tearDown step.
-
-If using test.TestCase, calling the super class setUp is required and
-calling the super class tearDown is required to be last if tearDown
-is overridden.
-
-Writing Functional Tests
-------------------------
-
-TBD
-
-Writing Integration Tests
--------------------------
-
-TBD
-
-Tests and Exceptions
---------------------
-A properly written test asserts that particular behavior occurs. This can
-be a success condition or a failure condition, including an exception.
-When asserting that a particular exception is raised, the most specific
-exception possible should be used.
-
-In particular, testing for Exception being raised is almost always a
-mistake since it will match (almost) every exception, even those
-unrelated to the exception intended to be tested.
-
-This applies to catching exceptions manually with a try/except block,
-or using assertRaises().
-
-Example::
-
-    self.assertRaises(exception.InstanceNotFound, db.instance_get_by_uuid,
-                      elevated, instance_uuid)
-
-If a stubbed function/method needs a generic exception for testing
-purposes, test.TestingException is available.
-
-Example::
-
-    def stubbed_method(self):
-        raise test.TestingException()
-    self.stubs.Set(cls, 'inner_method', stubbed_method)
-
-    obj = cls()
-    self.assertRaises(test.TestingException, obj.outer_method)
-
-
-Stubbing and Mocking
---------------------
-
-Whenever possible, tests SHOULD NOT stub and mock out the same function.
-
-If it's unavoidable, tests SHOULD define stubs before mocks since the
-`TestCase` cleanup routine will un-mock before un-stubbing. Doing otherwise
-results in a test that leaks stubbed functions, causing hard-to-debug
-interference between tests [1]_.
-
-If a mock must take place before a stub, any stubs after the mock call MUST be
-manually unset using `self.cleanUp` calls within the test.
-
-
-.. [1] https://bugs.launchpad.net/nova/+bug/1180671