tests(smokehouse): assert on expected array length

[connorjclark]

Extracted from #9248 (comment)

Proposal to change arrays in expectations to this behavior:

{
	expected: []
}

passes: []
fails: literally anything else

------------------------------

{
	expected: [1, 2, 3]
}

passes: [1, 2, 3]
fails: literally anything else

------------------------------

{
	expected: {length: 2}
}

passes: [1, 2] [1, 3] [x, y] {length: 2}
fails: [] [1] [1, 2, 3]

------------------------------

{
	expected: {0: 'a', 1: 'b'}
}

passes: ['a', 'b'] ['a', 'b', 'blah']
fails: ['b', 'a']

------------------------------

{
	expected: {0: 'a', 1: 'b', length: 3}
}

passes: ['a', 'b', *]
fails: ['a', 'b']

[connorjclark]

I admit this is not perfect.

But "I expect an array with these exact values, and no more" is more common than "I expect an array", so I'd rather [a, b, c] mean the former and not "expected array is a prefix of actual array"

[patrickhulce]

agreed the array use case is more important

definitely weird that IS_ARRAY is an object instead of an array though :)

maybe we can comment this one-time usage that we can't use an array and at least assert {length: '>0'} or something?

[patrickhulce]

LGTM % IS_ARRAY nit

[patrickhulce]

agreed the array use case is more important

definitely weird that IS_ARRAY is an object instead of an array though :)

maybe we can comment this one-time usage that we can't use an array and at least assert {length: '>0'} or something?

[patrickhulce]

should we do

path: `${path}.length`,

?

agreed that printing the full array value is best though

[brendankenny]

the "is" prefix is usually for tests. NONEMPTY_ARRAY seems better

[brendankenny]

(we also use this convention all over the expectations (e.g. dbw and byte-efficiency), so I'm not sure it's really worth calling out here in particular vs just inlining, but it's also fine if you want to keep)

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and have the pull request author add another comment and the bot will run again. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[googlebot]

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.