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
+9-8
Original file line number
Diff line number
Diff line change
@@ -50,13 +50,14 @@ All changes must be tested, I recommend writing the test first, then writing the
50
50
51
51
If you think that some of the added code is not testable (or testing it would add little value), mention that in your PR and we can discuss it.
52
52
53
-
1. If you're adding support for a new OpenAPI feature or covering a new edge case, add an [end-to-end test](#end-to-end-tests)
54
-
2. If you're modifying the way an existing feature works, make sure an existing test generates the _old_ code in `end_to_end_tests/golden-record`. You'll use this to check for the new code once your changes are complete.
55
-
3. If you're improving an error or adding a new error, add a [unit test](#unit-tests)
53
+
1. If you're adding support for a new OpenAPI feature or covering a new edge case, add [functional tests](#functional-tests), and optionally an [end-to-end snapshot test](#end-to-end-snapshot-tests).
54
+
2. If you're modifying the way an existing feature works, make sure functional tests cover this case. Existing end-to-end snapshot tests might also be affected if you have changed what generated model/endpoint code looks like.
55
+
3. If you're improving error handling or adding a new error, add [functional tests](#functional-tests).
56
+
4. For tests of low-level pieces of code that are fairly self-contained, and not tightly coupled to other internal implementation details, you can use regular [unit tests](#unit-tests).
56
57
57
58
#### End-to-end snapshot tests
58
59
59
-
This project aims to have all "happy paths" (types of code which _can_ be generated) covered by end-to-end tests. There are two types of these: snapshot tests, and unit tests of generated code.
60
+
This project aims to have all "happy paths" (types of code which _can_ be generated) covered by end-to-end tests. There are two types of these: snapshot tests, and functional tests.
60
61
61
62
Snapshot tests verify that the generated code is identical to a previously-committed set of snapshots (called a "golden record" here). They are basically regression tests to catch any unintended changes in the generator output.
62
63
@@ -71,17 +72,17 @@ There are 4 types of snapshots generated right now, you may have to update only
71
72
72
73
#### Functional tests
73
74
74
-
These are black-box tests that verify the runtime behavior of generated code, as well as the generator's validation behavior. For instance, they can verify that JSON data is correctly decoded into model class attributes, or that the generator will emit an appropriate warning for an invalid spec.
75
+
These are black-box tests that verify the runtime behavior of generated code, as well as the generator's validation behavior. They are also end-to-end tests, since they run the generator as a shell command.
75
76
76
-
This can sometimes identify issues with error handling, validation logic, module imports, etc., that might be harder to diagnose via the snapshot tests, especially during development of a new feature.
77
+
This can sometimes identify issues with error handling, validation logic, module imports, etc., that might be harder to diagnose via the snapshot tests, especially during development of a new feature. For instance, they can verify that JSON data is correctly decoded into model class attributes, or that the generator will emit an appropriate warning or error for an invalid spec.
77
78
78
79
See [`end_to_end_tests/functional_tests`](./end_to_end_tests/functional_tests).
79
80
80
-
#### Other unit tests
81
+
#### Unit tests
81
82
82
83
These include:
83
84
84
-
* Regular unit tests of basic pieces of fairly self-contained low-level functionality, such as helper functions. These are implemented in the `tests/unit` directory, using the `pytest` framework.
85
+
* Regular unit tests of basic pieces of fairly self-contained low-level functionality, such as helper functions. These are implemented in the `tests` directory, using the `pytest` framework.
85
86
* Older-style unit tests of low-level functions like `property_from_data` that have complex behavior. These are brittle and difficult to maintain, and should not be used going forward. Instead, they should be migrated to functional tests.
0 commit comments