Re: Unit tests and parameter validation

Thanks John.

Well I don't have to imagine it, I've seen which is what led to the
question. :)

Interesting perspective on contracts and the requirement to pass "correct"
inputs (avoiding the use of the word valid here) to get correct results.
 How does a consumer know what is correct however?

More to ponder....


On Tue, Oct 15, 2013 at 2:25 PM, John Goodsen <[email protected]> wrote:

> **
>
>
> Think in terms of the contract between the caller and the code.  The code
> guarantees valid results, ONLY IF the caller guarantees they'll pass in
> valid parameters.  So if passing a null is not part of that contract, you
> should not have to write tests and code to check if a null was passed.  Can
> you imagine if you started down the path of littering all your code with
> "if (foo == null) throw new Exception("Foo cannot be null") at the
> beginning of each method?  Don't do that.
>
> there's a big difference between checking is something is null and
> checking that a value is "valid".  Checking if a parameter is null is a
> code smell in most cases.  The only reason I'd ever check if something was
> null was if that lurking null pointer exception might not be found until
> later on in the program execution - in that case, I might Fail Early by
> throwing an exception.
>
> In the case of validating that the value pass passes some business
> validation rules, that might be an object waiting to be born, where you
> could check in a constructor that somebody is creating a bad object (e.g.
> the class "invariant") .. and I'd fail right there and then - you shouldn't
> have code later on that checks validity of values - don't let them be
> created in the first place.
>
>
>
>
> On Tue, Oct 15, 2013 at 10:41 AM, Eb <[email protected]> wrote:
>
>>
>>
>> Donald -
>>
>> If a test passes in the wrong input and fails initially, I see 3 general
>> ways of getting the test to pass:
>>
>>    1. Have your test look for the exception that will be thrown by the
>>    code
>>    2. Have your code validate the parameters to prevent an exception
>>    from being thrown
>>    3. Have you code substitute (handle in some other way) the bad
>>    parameter so that an exception is not thrown
>>
>> Or is the assumption that my code should never call the method with a bad
>> parameter, hence I shouldn't have a test that tests with bad parameter?
>>
>> Thanks.
>>
>>
>> On Tue, Oct 15, 2013 at 1:25 PM, Donaldson, John <[email protected]
>> > wrote:
>>
>>> **
>>>
>>>
>>>  Eb, ****
>>>
>>> ** **
>>>
>>> I agree with Colin in principle, but wider than that I’d say, following
>>> Uncle Bob’s rule of “no code without a failing test” pretty well ensures
>>> you will have tests which supply incorrect inputs, if you want to handle
>>> those cases.****
>>>
>>> ** **
>>>
>>> John D.****
>>>
>>> ** **
>>>
>>> *From:* [email protected] [mailto:
>>> [email protected]] *On Behalf Of *Colin Vipurs
>>> *Sent:* 15 October 2013 18:52
>>> *To:* [email protected]
>>> *Subject:* Re: [TDD] Unit tests and parameter validation****
>>>
>>> ** **
>>>
>>>
>>>
>>>
>>> ****
>>>
>>> If this is internal code only and the code calling it is also testing
>>> then I not only would I not test it but I'd remove all defensive code
>>> guards as well.  For example, a typical pattern would be:****
>>>
>>> ** **
>>>
>>> public void foo(SomeObject bar) {****
>>>
>>>    if (bar == null) {****
>>>
>>>    .....****
>>>
>>>    }****
>>>
>>> }****
>>>
>>> ** **
>>>
>>> Instead of catching the null and handling it, ensure all code calling it
>>> will never pass in null.  Cuts down on both test and production code.***
>>> *
>>>
>>> ** **
>>>
>>> On Tue, Oct 15, 2013 at 5:03 PM, Eb <[email protected]> wrote:****
>>>
>>>   ****
>>>
>>> Hello everyone -****
>>>
>>> ** **
>>>
>>> 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.****
>>>
>>> ** **
>>>
>>> Thanks.
>>> ****
>>>
>>> ** **
>>>
>>> -- ****
>>>
>>> blog: http://eikonne.wordpress.com****
>>>
>>> twitter: @eikonne****
>>>
>>>
>>>
>>> ****
>>>
>>> ** **
>>>
>>> --
>>> Maybe she awoke to see the roommate's boyfriend swinging from the
>>> chandelier wearing a boar's head.
>>>
>>> Something which you, I, and everyone else would call "Tuesday", of
>>> course. ****
>>>
>>>
>>>
>>>
>>> ****
>>>
>>> ****
>>>
>>>
>>
>>
>> --
>> blog: http://eikonne.wordpress.com
>> twitter: @eikonne
>>
>>
>>
>
>
> --
> [email protected]
> Public PGP
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x05699A00B7AD03E4
>
>   
>



-- 
blog: http://eikonne.wordpress.com
twitter: @eikonne