On Thu, 2023-03-16 at 09:38 -0700, Manu Bretelle wrote:
> [...]
>
> I was originally going to do a nested structure similar to this too
> (minus the repeat of test_* entries for subtests. But while discussing this
> offline with Andrii, a flatter structured seemed to be easier to parse/manage
> with tools such as `jq`. I am also very probably missing the right
> incantation for `jq`.
>
> Finding whether a test has subtests (currently only adding failed ones,
> but this could change in the future) would be easier (essentially checking
> length(subtests)). But neither is it difficult to reconstruct using
> higher level language.
>
`jq` query is a bit more complicated with nested structure, but not terribly so:
$ cat query.jq
.results | map([
.test_name,
(.subtests | map([([.test_name, .subtest_name] | join("/")) ]))
])
| flatten
$ jq -f query.jq test.json
[
"test_global_funcs",
"test_global_funcs/global_func16"
]
Test data for reference:
$ cat test.json | sed -r 's/"[^"]{20,}"/"..."/g'
{
"success": 1,
"success_subtest": 24,
"skipped": 0,
"failed": 1,
"results": [{
"test_name": "test_global_funcs",
"test_number": 223,
"message": "...",
"failed": true,
"subtests": [{
"test_name": "test_global_funcs",
"subtest_name": "global_func16",
"test_number": 223,
"subtest_number": 16,
"message": "...",
"is_subtest": true,
"failed": true
}
]
}
]
}
> In term of logical structure and maybe extensibility, this is more appropriate,
> in term of pragmatism maybe less.
>
> I don't have strong opinions and can see benefit for both.
idk, I don't have a strong opinion either.
> [...]
