Interesting, so how would you recommend fixing this test?
Ben
@Ben_Hall
When u talk about create manual mocks an stubs, do you mean create an entire class that "emulate" the behavior of a given class because this is a third party sealed class for example? Or do u mean to set the behavior of a given class with some mock framewrk like typemock, (in typemock's case you set the outcome with a method named "will return" that missused could lead to potential test issues)
"for example"?
It looks you forgot to cut&paste the example.
Totally agree. This is something I always point out in code reviews because it's very, very bad!
It also makes the test code less declarative -- instead of just saying what the result is meant to be, you are also saying _how_ to get the result.
Mark:
that's where the name of the test, as well as other factors (how simple is the test, how simple is the input\expected output) come in to play.
for example, you could name the expected 42 value in your post to a variable name that explains what the result means.
@Emilio
remove line 8 and chane line 9 to
Assert.AreEqual("hello user",result);
in this way you remove the logic bit from the test
Well, I never liked those rigid test name rules. Things change and stuff gets refactored and suddently, the class or method under test gets renamed, yet the test name remains the same.
For that reason I consider the test code the primary specification, and the name as secondary. I still prefer helpful test names, but I don't rely on them.
@smnbss: In your example, you would need two or more tests just to make sure the code didn't always return "Hello User" rather than the paramter. Would the following be better