Sure. Suppose you've just coded up a method. Your favored hypothesis is that your code is correct. Thus, you will find it harder to think of inputs likely to disconfirm this hypothesis than to think of inputs likely to confirm it.

Wason's 2-4-6 test provides a good illustration of this. You can almost directly map the hypothesis most people come up with to a method that returns "true" if the numbers provided conform to a certain rule. A unit test is a sample input that should cause the method to return false, which you could then check against the actual output of the Wason "oracle" (the actual criterion for being an acceptable triple).

Most people think more readily of confirmatory tests, that is, input data which conforms to their favored hypothesis. This will apply if you have already written the method.

This was noticed in the late 70's by testing authority Glenford Myers who derived from it the (misleading and harmful) edict "developers should never test their own code".

However, if you have to write the test first, you will avoid confirmation bias. You are less likely to harbor preconceptions as to the rule to be implemented, in fact you are actively thinking about test inputs that will invalidate the implementation, whatever that happens to be.

Does that help?