Re: Unit tests and parameter validation

Eb <[email protected]>
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CANEY99YGjfKhz0PS=Xvzap6+80JdH-vSh6rvDR8ciPKw-tfRdw@mail.gmail.com>
Exactly, bad habit! LOL.

Thanks Adam.


On Tue, Oct 15, 2013 at 8:33 PM, Adam Sroka <[email protected]> wrote:

> **
>
>
> Those i.e.s should have been e.g.s and by "customer doesn't expect an
> error" I meant customer expects not to see an error... That's what I get
> for writing emails at the bar
>
>
> On Tuesday, October 15, 2013, Adam Sroka wrote:
>
>> If a customer expects an error (i.e. I put in the wrong number, oops)
>> test for it. If a customer doesn't expect an error (i.e. WTF does "500
>> server error" mean, and how do I get this job done?) test for it. Anything
>> else, YAGNI, until you actually see it fail in exploratory testing, then
>> test for it.
>>
>> On Tuesday, October 15, 2013, Ron Jeffries wrote:
>>
>>> **
>>>
>>>
>>> Eb,
>>>
>>> On Oct 15, 2013, at 12:03 PM, Eb <[email protected]> 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
>>> www.XProgramming.com <http://www.xprogramming.com>
>>> 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: http://eikonne.wordpress.com
twitter: @eikonne
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.