ingydotnet
commented
6 years ago While this might be a good part of our lint/checking suite, the JSON is a data point that can be used to check something reading the event stream as input.
As I've mentioned elsewhere, the TestML data is hand maintained. That doesn't mean we can't use programs to check and even help generate new test cases, but it doesn't make sense to have test data that is 100% generated.
Note: some data points can be used as both inputs and outputs.
I wrote a program to calculate the expected JSON from the test.event file and got it to run comparisons against all the in.json files. I observed the following anomalies:
2JQS: Uses duplicate key values (both null) so is invalid YAML (from section 3.2.1.1 "The content of a mapping node is an unordered set of key: value node pairs, with the restriction that each of the keys is unique")
4ABK, 5WE3, 7W2P, 8KHE, C2DT, DBG4, FRK4: Omitted values should be represented as JSON null, not empty string.
8UDB: in.json is syntactically invalid.
DBG4: Unquoted numbers are represented as strings in in.json.
G4RS: The value for the "quoted" key in in.json is wrong (it should only have single quotes).
27NA, 2AUY, 2SXE, 2XXW, 35KP, 3GZX, 4GC6, 4UYU, 57H4, 5TYM, 6CK3, 6FWR, 6JWB, 6LVF, 6M2F, 6VJK, 6ZKB, 74H7, 77H8, 7A4E, 7BUB, 7FWL, 7T8X, 8G76, 96L6, 98YD, 9WXW, 9YRD, BEC7, BP6S, CC74, CUP7, DWX9, E76Z, EHF6, F2C7, FH7J, G992, HMQ5, HS5T, JHB9, JS2J, K527: in.json not included.