Proposal: have ETL tests disregard key order

Programming jq
1

I have solutions to ETL that are morally correct, but are rejected by the tests.

Specifically, when given

{ "1": "B", "2": "A" }

my solutions produce { "b": 1, "a": 2 }, whereas the tests ask for { "a": 2, "b": 1 }. These represent the same object; the only difference is the order in which the keys are printed.

Seeing as most other languages abstract this order away (so that this problem never comes up), and even in the realm of jq this should be a non-problem (see fix below), I propose to amend the tests to disregard key order.

Proposed patch (2 or 4 ×, or trackwide):

-    run jq -c    -f etl.jq << 'END_INPUT'
+    run jq -c -S -f etl.jq << 'END_INPUT'

@glennj, @IsaacG What do you think?

2

That sounds reasonable to me! I would want to quickly double check each exercise this is applied to in order to ensure the specific exercise doesn’t depend on ordering for correctness but that sounds like it ought to be right in most cases.

3

Sounds like a good idea to me as well.

The requirement for sorting the keys is just for convenience for the tests.
This is the only exercise where the example.jq uses sort_by on an object.

The tests could be written so they are not using bats commands for string comparison:

$ jq -n --argjson expected '{"a":1,"b":2}' --argjson actual '{"b":2,"a":1}' '$expected == $actual'
true

That would be extracted in a function

assert_objects_equal() {
    local result
    result=$(jq -n --argjson expected "$1" --argjson actual "$2" '$expected == $actual')
    [[ $result == "true" ]]
}

so the tests would read like

run jq ...
assert_success
expected='{"a":1}'
assert_objects_equal "$expected" "$output"

This approach would not need the jq -S option.

4

Small update:

I favored @glennj’s proposal, as I thought it was more obviously future proof.

However, I ran into some trouble trying to implement it. I tried adding assert_objects_equal to all bats-extra.bashes, modifying generate-tests, and regenerating all test-*.batses, but this goes wrong (or ‘wrong’) in several ways. Apparently the test files were already inconsistent between exercises, and also for some exercises several tests with the same name are generated, which results in a test error.

What do you imagine an ideal patch would look like here?

I can look into this again, later.

5

I would add it in test-etl.bats after load bats-extra – it’s only needed in this one exercise.