should we consider a follow up to change all usages of require.Equal, just so we don't end up with inconsistent usage throughout the repo?

A couple of reasons why I didn't do that already:

• Package model/labels, which testutils imports, cannot use the new function because that would create an import cycle.
  Possibly I can break that cycle by introducing a third package.
• Every place you make this change you need to think about unexported fields, since go-cmp will panic if it knows nothing about them. This is an ongoing burden as data structures evolve.

I'm interested to hear what anyone else thinks.

should we consider a follow up to change all usages of require.Equal, just so we don't end up with inconsistent usage throughout the repo?

A couple of reasons why I didn't do that already:

• Package model/labels, which testutils imports, cannot use the new function because that would create an import cycle.
  Possibly I can break that cycle by introducing a third package.
• Every place you make this change you need to think about unexported fields, since go-cmp will panic if it knows nothing about them. This is an ongoing burden as data structures evolve.

I'm interested to hear what anyone else thinks.

Yep, was just thinking about it as a follow up not in this PR. Your third point is a compelling one for not doing so though. But my question then would be how we can document and make recommendations about when the testutil comparison should be used over deep equal.