|
Let's assume you have a method similar to this one:
public void SomeMethod(string myParam) {
if (string.IsNullOrEmpty(myParam) {
throw new Exception();
}
}
When writing unit tests do you write tests that cover all of the variations of what could trip the exception?
i.e. one test each where
myParam = null
myParam = string.empty
myParam = " "
Or do you just write one of the above tests?
I tend to write all 3 tests. And, similarly, if a positive integer is required I'll have a test for the integer being 0 and one for it being < 0 since the operators are potentially different.
Just wondered what you guys thought, and if I'm overdoing the testing.
Andrew
"My days of not taking you seriously are certainly coming to a middle."
|
|
|
|
|
What you are "testing" is the IsNullOrEmpty function; I'll test with either one, fully confident that the method will behave as documented. When I test, I test my own code, not the frameworks' methods.
|
|
|
|
|
I guess my thought was that I testing to make sure someone didn't change the actual call to IsNullOrWhiteSpace. In theory a future dev could change my IsNullOrWhiteSpace to IsNullOrEmpty and effectively break the method by allowing it to accept an string of whitespace.
I might be being too much of a control freak though.
|
|
|
|
|
Andrew Stoute wrote: In theory a future dev could change my IsNullOrWhiteSpace to IsNullOrEmpty and effectively break the method by allowing it to accept an string of whitespace.
In that case, the only good test would be to compare the methods' body to the actual source-code you have now.
Don't let people change your code if they don't know what they're doing. Any nitwit could guess that if the method behaves different (translate to 'unexpected') that things will break. On a class-level, this is the L[^] from the SOLID principle. Simplest example; don't throw any exceptions that weren't already in the base-class (as the applications' try..catch constructs will not expect it, and break).
|
|
|
|
|
Andrew Stoute wrote: I might be being too much of a control freak though.
Not at all. The backup to this is documenting that it cannot accept whitespace and you may even rewite the code to strip leading and trailing whitespace characters to defend against it.
|
|
|
|
|
You're also testing what would happen based on the types of data that you're sending it. If, somewhere down the road, the data you're sending the method changes, you may need to document that the method can handle those changes as expected, such as sending a string of space and tab characters.
Personally, I would be checking to see if an actual string was passed in, THEN stripping the data of leading and trailing whitespace if required and then checking for an empty string. String.IsNullOrEmpty doesn't check to see if the string contains non-whitespace characters.
|
|
|
|
|
Dave Kreskowiak wrote: Personally, I would be checking to see if an actual string was passed in, THEN
The parameter only accepts strings, making this test superfluous.
Dave Kreskowiak wrote: stripping the data of leading and trailing whitespace if required and then checking for an empty string. String.IsNullOrEmpty doesn't check to see if the string contains non-whitespace characters.
Personally, I don't care for "whitespace"; if a user wants to store three spaces, a tab and a newline, then that's what gets stored. The only place where you "might" want to check it, is when validating input. Remember the NT4-server shutdown dialog? Required a non-null "reason". Did it help? No, a single period was "reason" enough.
|
|
|
|
|
Eddy Vluggen wrote: The parameter only accepts strings, making this test superfluous.
You would check for mull before trying to work with the string?? I don't see how that's superfluous.
Eddy Vluggen wrote: Personally, I don't care for "whitespace"; if a user wants to store three
spaces, a tab and a newline, then that's what gets stored. The only place where
you "might" want to check it, is when validating input.
User's aren't the only source of input that makes your code go "WTE!?" Foreign systems, poor XML files, non-normallized data in a database you inherit, corruption from a poor communications channel, ... the list goes on. You can get a blank or string formatted in some way your code doesn't expect from any number of sources. I was always taught that a method should be written to defend itself against pontentially bad data.
|
|
|
|
|
Dave Kreskowiak wrote: You would check for mull before trying to work with the string?? I don't see how that's superfluous.
"NullOrEmpty".
Dave Kreskowiak wrote: poor XML files
XML doesn't care much for whitespace.
Dave Kreskowiak wrote: I was always taught that a method should be written to defend itself against pontentially bad data.
I'm not putting an XML-validator in there 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
