I would encourage use of an existing function to check for emptiness, but require a particular argument for it to be considered "the right way:"
test_cmp /dev/null actual This means less vocabulary to memorize for test writers. It's usually a code smell to have special logic for a specific value for a specific argument - a sign that a separate function ought to be created - but since we want to add an error or warning in test_cmp anyway when <EXPECTED> is empty, I think this special logic is OK. As for comparing against a file that *might* be empty, like a utility function, might I suggest requiring the file name be formatted in a specific way if it may be empty? Like require a certain substring. Then the syntax for comparison would be: # If the emptiness is unconditional test_cmp /dev/null actual # If the emptiness is unknown ahead of time test_cmp maybe_empty_expected actual Then, issue an error for something like: > expected && test_cmp expected actual which says: " Use test_cmp /dev/null <ACTUAL> to verify a file is empty. If the <EXPECTED> file may or may not be empty (as in a utility function), include the string "maybe_empty" in the <EXPECTED> file name. "
