0.5 tests #51
0.5 tests #51
Conversation
They are semantically the same so a parse should not be expected to keep the distinction. The object with type 'array' is eliminated and all arrays are expected to be encoded as json arrays.
|
If anyone looks at this PR, I also eliminated the distinction between table arrays ([[...]]) and "inline" arrays of tables ([{...},{...}]). Toml-test was expecting them to be encoded as json arrays and as a special json object with a 'type' property set to 'array' respectively. Since a parser should not be expected to keep the distinction (they are semantically equal), I consider that asking a parser to encode them differently for testing purposes is an error. In all cases they are expected in this PR to be encoded as regular json arrays. |
|
@sgarciac I am not sure if I can agree with "semantically equal" here. There is a clear distinction between an inline array of tables and an [[array.of.tables]]. The difference is that the latter can be appended to by defining more of them, while inline arrays are static by definition. Theferore, especially the parser must be aware of these semantics and I'd find it more correct to have this represented in a test, when testing the parser. When testing the resulting data set, one might not be interested in this distinction. From the perspective of the code that uses the resulting data set, there indeed is no different between the two. I'm okay with this situation, but in my case it does mean that I have to hide parser details like this one to make the tests work, which means that some functional testing is lost there. |
|
Hi @mmakaay , as far as I understand it, toml-test tests "decoders" and is only concerned about the validity of the resulting data. The distinction you describe between inline arrays of tables and [[array of tables]] is an internal detail of the parser for which toml-test should not really care. |
|
Yes, I agree with that and I have plenty of internal unit tests that test for the correct parser behavior. The main reason for reacting was "Since a parser should not be expected to keep the distinction (they are semantically equal)". Apparently you meant that the distinction should not be kept after the parsing process has completed. I read it as if you meant that the parser internals couldn't be expected to keep track of the difference during parsing, so misinterpretation of your quote on my side. |
I think this is fine; this repo is intended as a big bag of valid and invalid TOML files you can throw at your library and tool to see if it works roughly correct. We can't test every possible condition, and you're still going to need unit tests. I took over maintainership last week; I need to fix a few remaining things in the Go TOML library to support TOML 0.5, and I'll merge this once I'm done with it. Otherwise I'll have a ton of failing test in the library, which is rather annoying 😅 |
|
Merged via #70 There were quite a few conflicts, and a number of tests were already added in the meantime, or needed some other minor change, so it was easiest to do it like this 😅 I had intended to keep your commit(s) and base it off that, but it seems my git-fu failed on that somehow and I didn't notice until after I merged, so I'm recorded as the only author, sorry about that :-( |
This PR add tests to cover version 0.5 of the specification.
Notes: