¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Topics

[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 <amaeze@...> 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:
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.

 

Thanks for your responses.

Colin - what if another developer would be using it (and not the originally creator). ?How does he/she know that passing in null (for example) is wrong?


On Tue, Oct 15, 2013 at 12:52 PM, Colin Vipurs <zodiaczx6@...> wrote:
?

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 <amaeze@...> 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:
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:
twitter: @eikonne
Donaldson, John
 

¿ªÔÆÌåÓý

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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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.




 

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 <john.m.donaldson@...> 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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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:
twitter: @eikonne
John Goodsen
 

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 <amaeze@...> 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 <john.m.donaldson@...> 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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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:
twitter: @eikonne





--
Public PGP

 

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 <jgoodsen@...> 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 <amaeze@...> 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 <john.m.donaldson@...> 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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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:
twitter: @eikonne





--
Public PGP




--
blog:
twitter: @eikonne
John Goodsen
 


On Tue, Oct 15, 2013 at 11:42 AM, Eb <amaeze@...> wrote:
More to ponder....

I tend to program in a more functional style these days, so you can write much more concise, if-less code ... if you want your data in a collection to be "valid", for example, you flatMap over it and morph the data into a temporary shape that you need (e.g. add some fields, reject values meet some criteria, etc... ... which means I pretty much never have code that validates data anymore and I rarely have if statements in the code at all, because once the data looks like the code wants it to look like, you just let the code do it's thing- sometimes I'll throw in a check temporarily to debug some tests or when we're getting an API right, but then I'll remove those data checks once we're confident they aren't needed anymore...


--
Public PGP

 

On 10/15/13 11:42 AM, Eb wrote:
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?
A consumer must be told the specific semantics to expect. One way is to
read the code. In the absence of code you must rely on documentation.
Executable documentation in the form of code examples that also serve as
tests for validation is just one way to communicate the semantics.

--
Edwin G. Castro
 

Hi Edwin -

So what's your opinion on what to actually do? ?What would the tests look like?

Thanks.

Ebenezer


On Tue, Oct 15, 2013 at 3:09 PM, Edwin Castro <egcastr@...> wrote:
On 10/15/13 11:42 AM, Eb wrote:
> 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?

A consumer must be told the specific semantics to expect. One way is to
read the code. In the absence of code you must rely on documentation.
Executable documentation in the form of code examples that also serve as
tests for validation is just one way to communicate the semantics.

--
Edwin G. Castro



------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
? ?

<*> Your email settings:
? ? Individual Email | Traditional

<*> To change settings online go to:
? ?
? ? (Yahoo! ID required)

<*> To change settings via email:
? ? testdrivendevelopment-digest@...
? ? testdrivendevelopment-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
? ? testdrivendevelopment-unsubscribe@...

<*> Your use of Yahoo! Groups is subject to:
? ?




--
blog:
twitter: @eikonne
 

Eb,
All these? behaviors can be valid.
The actual question in my opinion, is what would you expect your production code to do?
Should it validate the inputs?
What should it do if "bad" inputs are given?
After you (and your team) decide on the needed? behavior, it will be very easy to TDD it.

Hope this make sense
Lior

On Oct 15, 2013 8:41 PM, "Eb" <amaeze@...> 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 <john.m.donaldson@...> 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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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:
twitter: @eikonne
 

On 10/15/13 12:42 PM, Eb wrote:
On Tue, Oct 15, 2013 at 3:09 PM, Edwin Castro wrote:
On 10/15/13 11:42 AM, Eb wrote:
> 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?

A consumer must be told the specific semantics to expect. One way is to
read the code. In the absence of code you must rely on documentation.
Executable documentation in the form of code examples that also serve as
tests for validation is just one way to communicate the semantics.

So what's your opinion on what to actually do? What would the tests
look like?
What is appropriate for your team depends on your culture and the
requirements around how semantics are communicated between developers in
your team, developers in other teams consuming your work, QA, etc.

There are no fast rules, only principles and guidelines. Executable
documentation in the form of tests is preferable to traditional API
references or developer guides because tests have a tendency to break
when the documentation is out of date.

An acceptance test that validates that an exception is thrown and that
no side effects have occurred provides a way to explicitly document the
semantics of the method.

The specific exception validated by the test is perhaps not as important
from the test's perspective but we do want to provide valuable
information to the developers consuming our work so they can fix their
error.

An acceptance test that validates no side effects occur will alert us
when we accidentally break our documented semantics in a way that could
negatively impact consumers.

As others have mentioned, the client code should be responsible for not
passing you a null value. Your code is likely also client code for other
code so you'll need to make sure you are not accidentally passing nulls
to other code. This is an important quality to validate in unit tests.

--
Edwin G. Castro
 

Lior -

Sure.

Eb


On Tue, Oct 15, 2013 at 4:16 PM, Lior Friedman <lfriedmal@...> wrote:
?

Eb,
All these? behaviors can be valid.
The actual question in my opinion, is what would you expect your production code to do?
Should it validate the inputs?
What should it do if "bad" inputs are given?
After you (and your team) decide on the needed? behavior, it will be very easy to TDD it.

Hope this make sense
Lior

On Oct 15, 2013 8:41 PM, "Eb" <amaeze@...> 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 <john.m.donaldson@...> 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: testdrivendevelopment@... [mailto:testdrivendevelopment@...] On Behalf Of Colin Vipurs
Sent: 15 October 2013 18:52
To: testdrivendevelopment@...
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 <amaeze@...> 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:

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:
twitter: @eikonne




--
blog:
twitter: @eikonne

1 - 12 of 12