When a function that accepts input and returns a value of a certain type is tested it is straightforward: we pass values as parameters to the function and we verify that the output of that function equals to the expected value. An obvious example is when we’re testing a function that sums two numbers. Let's use the prototype addIntegers(A → Integer, B → Integer) → Integer. We can test with the input values 2 and 3 and we can expect that the outcome is 5.
When the function you’re testing does not emit an output, you can’t test the result of it. Instead, you verify that an effect occurred, but you also have to make sure that the effect occurred because you wanted it to occur. For example, testing the function honkIfYouSupportCanada() → Void is a hard problem to solve. You could run the function and track the sound emitting subsystem to verify if a honk occurred. If you run the function and honking doesn’t happen, was it because the function failed or was it because the computer does not like Canada and the function actually worked as expected? If you run the function and the honk actually occurs you can guess that the conditions were met and the test is good, but you could still be wrong and the honk could have been unrelated. In order to assume that your test is correct you have to generalize it, parametrize it, and pass specific input: honkIfItemIsSupported(itemSupport → Boolean, honker → HonkingSubsystem) → Void. Now you have a high level of confidence that honks happen or not in relation with the input.