Updating contributing doc to include dev workflow improvements

CONTRIBUTING.md

@@ -112,16 +112,25 @@ However, *DO NOT* be afraid to say, "that looks terrible", and tweak it until it
 
 #### Tests
 
-1. Assume the following when creating and naming your test:
-   a. Someone will come in cold to the entire project.
+1. Assume the following when creating and naming your test:<br>
+   a. Someone will come in cold to the entire project.<br>
    b. The tests will be used by API users to guide their client application designs
-3. For repeated tests with different, but very similar data, ParameterizedTests are preferred.
+3. For repeated tests with different, but very similar data, ParameterizedTests are preferred.<br>
 4. 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.
 5. 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)
 6. Prefer disabling test by database schema version, if that does work use `EnabledIfProperty` and share a property name between related tests.
 7. Use "real" names for data in test data set. Either use actual real location/project/basin/etc names, or make up something that feels like one.
   a. NOTE: within reason. Location names, absolutely, but otherwise make sure the purpose of the name is clear.
 8. Name files consistent with the purpose of the test.
+9. Narrative tests: Test method names should be a narrative summary of the test. For example, `test_stream_create_then_update_then_delete_success()`. <br>
+  a. Use underscores to make the narrative structure of the test name clear.<br>
+  b. The method name should be a clear summary of what is being tested (create, get, update, delete) in order of operations. Not how the above example follows this with use of <i>then</i><br>
+  c. It should also include the expected result (success, error code, etc.)<br>
+  d. Comments should also be used in narrative flow to clarify the details of the test internally, but not as a substitute for a clear method name. (example: [StreamControllerTestIT comments](https://github.com/USACE/cwms-data-api/blob/a1d265372ead2db0123b74ff0ffa6c76a7e21949/cwms-data-api/src/test/java/cwms/cda/api/StreamControllerTestIT.java#L124)<br>
+  e. Setup and tear down methods should also be clearly labelled as such. Setup/teardown methods should call into well-named helper methods to clarify the purpose of the setup/teardown steps.<br>
+   (example: setup method calls helper method `create_test_location()` followed by `create_test_time_series()` to clarify the purpose of the setup step<br>
+    likewise, the tear down method calls helper method `delete_test_time_series()` followed by `delete_test_location()` to clarify the purpose of the tear down step)<br>
+
 
 
 
@@ -147,6 +156,10 @@ Please [fork](https://help.github.com/en/articles/fork-a-repo) the repository on
 Once you have made your changes submit a [pull request](https://help.github.com/en/articles/creating-a-pull-request-from-a-fork).
 Please submit all PRs to the develop branch.
 
+If there is an OpenAPI change, the pull request should include a screenshot of the Swagger UI showing the change 
+under the docs/source/swagger-screenshots directory (for example, see [Locations.png](https://github.com/USACE/cwms-data-api/blob/abfa3d8cd6cd9cd79c8435761fa95c447e534afc/docs/source/swagger-screenshots/Locations.png)).
+![Swagger UI change example](docs/source/swagger-screenshots/Locations.png)
+
 Barring nothing working at all or the code not being related to CWMS Data API your contributions will be accepted.