Design notes.

CONTRIBUTING.md

@@ -101,6 +101,21 @@ However, *DO NOT* be afraid to say, "that looks terrible", and tweak it until it
        Otherwise JOOQ creates a new name each time the query is run which can starved the shared memory.
 
 2. Joins are your friend. They are a much better friend IF you let the database do them for you. Do not pull data into java just to do a join. Write the appropriate SQL.
+3. Whenever possible limit by office first.
+
+#### Database version support
+
+1. Given we have active development of both the API and the database and things are not always available at the same time, it is reasonable to gate new features behind a database version check and return an appropriate error message.
+   This is preffered over default errors of things not working
+
+2. If it is known that an integration test requires a specific database version it should be gated behind a EnableIfSchemaVersion (NOTE: not implemented at the time of this writing) annotation so streamline automated testing results.
+
+#### JUnit
+
+1. For repeated tests with different, but very similar data, ParameterizedTests are preferred.
+2. In integration tests for data that should be cleaned up after all tests register them with the functions available in the base class. Create if reasonable.
+3. If it adds clarity, do not be afraid to use the `@Order` annotation to sequence tests. (See the [ApiKey Controller Test](https://github.com/USACE/cwms-data-api/blob/develop/cwms-data-api/src/test/java/cwms/cda/api/auth/ApiKeyControllerTestIT.java) for an example)
+4. Prefer disabling test by database schema version, if that does work use `EnabledIfProperty` and share a property name between related tests.
 
 ## Submitting an Issue