Is it wise to do "the testing" by "writing checks" by the same developer as the one creating the code?

As usual, there isn't an absolute answer here. Here are some things that I might consider:

1. Is there only one programmer?
2. Could the programmer pair with another programmer?
3. Could the programmer pair with someone other than a programmer?
4. Is the programmer experienced at writing checks?
5. Is the programmer sloppy, hygenic, or obsessive-compulsive about his checks?
6. Is there reason to believe that the programmer needs help with doing this?
7. Is this a new or risky part of the code?
8. Are there already a bunch of checks for this code, written by this programmer?
9. Are there already a bunch of checks for this code, written by another programmer?
10. Is this code a total prototype, or is there a chance that it's heading for production?
11. Does the programmer appreciate help, or does he feel neutral, or does he reject it? Why?
12. Is the programmer going to be evaluated based on the checks? If so, how? How might the evaluation distort our bigger goals?
13. Does the initiative to check come from the programmer, his colleagues, his manager, or someone else? How might the mandate support or distort matters?

—Michael B.

In the reply to Joe, James says:
"Strictly speaking you are "doing testing" by "writing checks", but not actually "writing tests."".

I am still pondering about the following:
Is it wise to do "the testing" by "writing checks" by the same developer as the one creating the code? (and possibly risk tunnel visioning?). When you seperate these two steps, the actual checking (on running code) could be expanded with "testing".