Re: Unit tests and parameter validation

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