@@ -5,11 +5,11 @@ contains a runner and language-specific harnesses to confirm feature behavior ac
5
5
6
6
These SDK features serve several purposes:
7
7
8
- * Ensure parity across SDKs by having same-feature snippets adjacent to one another
9
- * Confirm feature behavior across SDK versions
10
- * Confirm history across SDK versions
11
- * Document features in different SDKs
12
- * Easy-to-use environment for writing quick workflows in all languages/versions
8
+ - Ensure parity across SDKs by having same-feature snippets adjacent to one another
9
+ - Confirm feature behavior across SDK versions
10
+ - Confirm history across SDK versions
11
+ - Document features in different SDKs
12
+ - Easy-to-use environment for writing quick workflows in all languages/versions
13
13
14
14
## Building
15
15
@@ -87,38 +87,42 @@ the `features/` directory.
87
87
In addition to code for the feature, there are configuration settings that can be set in ` .config.json ` . The possible
88
88
settings are:
89
89
90
- * ` go `
91
- * ` minVersion ` - Minimum version in Go this feature should be run in. The feature will be skipped in older versions.
90
+ - ` go `
91
+ - ` minVersion ` - Minimum version in Go this feature should be run in. The feature will be skipped in older versions.
92
92
93
93
There are also files in the ` history/ ` subdirectory which contain history files used during run. See the
94
94
"History Checking" and "Generating History" sections for more info.
95
95
96
96
### Best Practices
97
97
98
- * Try to only demonstrate/test one feature per feature directory.
99
- * Code should be kept as short and clear as possible.
100
- * No need to over-assert on a bunch of values, just confirm that the feature does what is expected via its output.
101
- * A Go feature should be in ` feature.go ` .
102
- * For incompatible versions, different files like ` feature_pre1.11.0.go ` can be present using build tags
103
- * A Java feature should be in ` feature.java ` .
104
- * A TypeScript feature should be in ` feature.ts ` for all non-workflow code and ` feature.workflow.ts ` for all workflow
105
- code.
106
- * A Python feature should be in ` feature.py ` .
107
- * Add a README.md to each feature directory.
108
- * README should have a title summarizing the feature (only first letter needs to be in title case), then a short
98
+ - Try to only demonstrate/test one feature per feature directory.
99
+ - Code should be kept as short and clear as possible.
100
+ - No need to over-assert on a bunch of values, just confirm that the feature does what is expected via its output.
101
+ - A Go feature should be in ` feature.go ` .
102
+ - For incompatible versions, different files like ` feature_pre1.11.0.go ` can be present using build tags
103
+ - A Java feature should be in ` feature.java ` .
104
+ - A TypeScript feature should be in ` feature.ts ` .
105
+
106
+ ** NOTE** : TypeScript features include workflow and non workflow code in the same file. Those are run in different
107
+ environments so they may not share variables and the feature author should keep the workflow runtime limitations in min
108
+ mind when writing features.
109
+
110
+ - A Python feature should be in ` feature.py ` .
111
+ - Add a README.md to each feature directory.
112
+ - README should have a title summarizing the feature (only first letter needs to be in title case), then a short
109
113
paragraph explaining the feature and its purpose, and then optionally another paragraph explaining details of the
110
114
specific code steps.
111
- * Other sections can also explain decisions made in language specific ways or other details about versions/approaches.
112
- * Feel free to add links and more text as necessary.
113
- * Verification/regression feature directories for bugs should be under ` features/bugs/<lang> ` .
114
- * Ideally the checking of the result has a version condition that shows in earlier versions it should fail and in
115
+ - Other sections can also explain decisions made in language specific ways or other details about versions/approaches.
116
+ - Feel free to add links and more text as necessary.
117
+ - Verification/regression feature directories for bugs should be under ` features/bugs/<lang> ` .
118
+ - Ideally the checking of the result has a version condition that shows in earlier versions it should fail and in
115
119
newer versions it should succeed.
116
- * The more languages per non-bug feature, the better. Try not to create non-bug features that use specific language
120
+ - The more languages per non-bug feature, the better. Try not to create non-bug features that use specific language
117
121
constructs unless that's the purpose of the feature.
118
- * Refactor liberally to create shortcuts and better harnesses for making features easy to read and write.
119
- * This is not a library used by anyone, there are no backwards compatibility concerns. If one feature uses something
122
+ - Refactor liberally to create shortcuts and better harnesses for making features easy to read and write.
123
+ - This is not a library used by anyone, there are no backwards compatibility concerns. If one feature uses something
120
124
that has value to another, extract and put in helper/harness and have both use it.
121
- * History should be generated for each feature on the earliest version the feature is expected to work at without
125
+ - History should be generated for each feature on the earliest version the feature is expected to work at without
122
126
history changes.
123
127
124
128
#### Generating History
@@ -132,15 +136,16 @@ incompatibility. Otherwise, history files should remain checked in and not regen
132
136
133
137
## TODO
134
138
135
- * Add support for replaying testing of all versions _ inside_ each SDKs harness as part of the run
136
- * Add TypeScript support
137
- * The main support is present, but there are outstanding questions on what constitutes a "version" since really
139
+ - Add support for replaying testing of all versions _ inside_ each SDKs harness as part of the run
140
+ - Add TypeScript support
141
+ - The main support is present, but there are outstanding questions on what constitutes a "version" since really
138
142
TypeScript has many versions
139
- * Add many more feature workflows
140
- * Document how to use this framework to easily write and test features even when not committing
141
- * Log swallowing and concurrent execution
142
- * Investigate support for changing runtime versions (i.e. Go, Java, and Node versions)
143
- * Investigate support for changing server versions
144
- * CI support
145
- * Support using a commit hash and alternative git location for an SDK to run against
146
- * Decide whether the matrix of different SDK versions and such is really part of this repo or part of CI tooling
143
+ - Add many more feature workflows
144
+ - Document how to use this framework to easily write and test features even when not committing
145
+ - Log swallowing and concurrent execution
146
+ - Investigate support for changing runtime versions (i.e. Go, Java, and Node versions)
147
+ - Investigate support for changing server versions
148
+ - CI support
149
+ - Support using a commit hash and alternative git location for an SDK to run against
150
+ - Decide whether the matrix of different SDK versions and such is really part of this repo or part of CI tooling
151
+
0 commit comments