Re: [TDD] Unit tests and parameter validation
|
Thanks Ron.
It sounds like you test/develop outside in. ?Is my inference wrong? ?Curious how if this changes if one develops inside out. ?Probably the statement would that be we will be writing tests for the code that calls the code currently being developed.
Definitely, this is defensive coding.
Eb
On Tue, Oct 15, 2013 at 7:42 PM, Ron Jeffries <ronjeffries@...> wrote:
?
Eb, On Oct 15, 2013, at 12:03 PM, Eb < amaeze@...> wrote:
I'm curious to know thoughts on writing tests that specify the behavior of a method when its inputs are incorrect. ?Is this a common practice. ?How about parameter validation in this case? ?Having some healthy debate on it and wanted to get other insight.
The context for this in a class/methods that are used within an internal application - this is not an API that will be publicly exposed to external consumers.
Generally speaking, I do not check arguments for correctness. If I am building the entire app via TDD, the code that calls the method is already tested, and therefore in fact calls with correct arguments.
If the method in question is potentially harmful, then I will be more inclined to cause it to protect itself, and I would generally test that.
This approach generally works for me. My experience is that "defensive" code generally makes the program much larger, increases its complexity, and since the defensive code is both arcane and hard to test, it usually embodies a disproportionate number of defects.?
So I focus on writing correct code, not code that lives in fear of its neighbors.
Ron Jeffries
I have two cats, and a big house full of cat stuff.? The cats fight and divide up the house, messing up their own lives.? Nice work cats.? Meow.
-- blog:
twitter: @eikonne
|
