You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+11Lines changed: 11 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -122,6 +122,14 @@ However, *DO NOT* be afraid to say, "that looks terrible", and tweak it until it
122
122
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.
123
123
a. NOTE: within reason. Location names, absolutely, but otherwise make sure the purpose of the name is clear.
124
124
8. Name files consistent with the purpose of the test.
125
+
9. Narrative tests: Test method names should be a narrative summary of the test. For example, `test_stream_create_then_update_then_delete_success(...)`.
126
+
a. Use underscores to make the narrative structure of the test name clear.
127
+
a. The method name should be a clear summary of what is being tested (create, get, update, delete) in order of operations.
128
+
b. It should also include the expected result (success, error code, etc.)
129
+
c. 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.
130
+
d. 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.
131
+
(example: setup method calls helper method `create_test_location()` followed by `create_test_time_series()` to clarify the purpose of the setup step)
132
+
125
133
126
134
127
135
@@ -147,6 +155,9 @@ Please [fork](https://help.github.com/en/articles/fork-a-repo) the repository on
147
155
Once you have made your changes submit a [pull request](https://help.github.com/en/articles/creating-a-pull-request-from-a-fork).
148
156
Please submit all PRs to the develop branch.
149
157
158
+
If there is an OpenAPI change, the pull request should include a screenshot of the Swagger UI showing the change
159
+
under the docs/swagger-screenshots directory (for example, see [Locations.png](https://github.com/USACE/cwms-data-api/blob/abfa3d8cd6cd9cd79c8435761fa95c447e534afc/docs/source/swagger-screenshots/Locations.png)).
160
+
150
161
Barring nothing working at all or the code not being related to CWMS Data API your contributions will be accepted.
0 commit comments