To summarize the problem:
The general expectation of unit tests is that they continue to work right; that is, ring the bell when something breaks but play nice when everything still works right.
With 'refactoring' features like ie Eclipse's 'rename method' having a much harder time extending in purely runtime/reflection jokes like passing a method name using a String - writing unit tests like in your example means every little refactor breaks a whole bunch of unit tests, and the bore of fixing them all will either cause you to:
A) Ditch your unit tests, or
B) Leave stupid method names intact because changing them is such a drag, eventhough eclipse and other modern dev environments try to make it a painless process with refactoring wizards.
Beside all this, what the hell is the point of writing a unit test that consists of: This method should call method X exactly once and then get '10' back?
The problem with unit tests is that you can't automatically test everything. For some things unit tests are the clear answer to good programming. For some things, like writing a GUI, unit tests are difficult to get right. Resorting to this kind of fabricated crap just to say you have a unit test is typical by-the-book OO/java developer. Entirely proper, extremely slow, and not very useful at all.
Having said all this, your article requires such a large amount of experience with programming in general and unit tests in particular, that I seriously doubt this article will make it.
NB: reflection = to be avoided as much as possible. 'hard reflection' (where you use reflection eventhough all you're using it for is hardcoded names, such as in your example) is to be avoided absolutely. If there's no way to write a unit test without hard reflection then you ARE better off not writing it or coming up with a different solution altogether. I have and do use reflection, but, oftentimes, when I return to the code at a later date, I manage to get rid of it by doing things a little different.
"is a signature" is a signature.