¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: [TDD] Unit tests and parameter validation

 

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
Re: [TDD] Unit tests and parameter validation

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

Re: [TDD] 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 <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
Re: [TDD] Unit tests and parameter validation

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

Re: [TDD] Unit tests and parameter validation

 

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
Re: [TDD] Unit tests and parameter validation

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.




Re: [TDD] Unit tests and parameter validation

 

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
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.

Re: [TDD] Unit tests and parameter validation

 

It depends on the language, but in general, I think it should be tested. ?

brought to you by the letters A, V, and I
and the number 47


On Tue, Oct 15, 2013 at 7: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
Unit tests and parameter validation

 

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
Re: [TDD] Unit testing in C++11

Osias Jota
 

Good! :)


2013/7/25 Joakim Karlsson <joakim@...>

**


Although there are an abundance of unit testing frameworks for C++ out
there, I decided to learn some of the features available in C++11 by
writing yet another one.

At this point it's mostly for play and to scratch an itch. I wanted to
bring the good parts of writing unit tests in other environments with a
quick setup, readable tests, no hardwiring to a specific assertion
framework, and ease of organizing test hierarchies so that setups for a
context can be easily reused and augmented by sub contexts.

Anyway, there's a lot of subjectivity here, but if you find this
interesting please take a look and let me know what you think.



/ Joakim

[Non-text portions of this message have been removed]




--
Osias, o Osias


[Non-text portions of this message have been removed]
Unit testing in C++11

Joakim Karlsson
 

Although there are an abundance of unit testing frameworks for C++ out
there, I decided to learn some of the features available in C++11 by
writing yet another one.

At this point it's mostly for play and to scratch an itch. I wanted to
bring the good parts of writing unit tests in other environments with a
quick setup, readable tests, no hardwiring to a specific assertion
framework, and ease of organizing test hierarchies so that setups for a
context can be easily reused and augmented by sub contexts.

Anyway, there's a lot of subjectivity here, but if you find this
interesting please take a look and let me know what you think.



/ Joakim
Re: [TDD] Mocking collaborators that are third-party libraries

 

George -

Answer is clearer and I am reminded of the two (complimentary) approaches.

Thanks.


On Thu, Jul 11, 2013 at 6:17 PM, George Dinwiddie
<lists@...>wrote:

**


Eb,


On 7/11/13 5:35 PM, Eb wrote:
Thanks George.

I am following that advice also (already) so very good to get affirmation
of that.

However, I realize my question was not clear enough so continuing from
your
answer, do you always verify behavior on mocked adaptors or are there
occasions where you don't? That is, you just mock them but don't verify.
I tend to use a state-based approach (aka "Detroit style") so I'm
usually verifying the result of the behavior. Often my test doubles are
simple fakes (data sources) or stubs (data sinks, but usually query-able
by the test).

When I'm testing with a test-double adapter, I try to be cognizant of
the assumptions I'm making about the 3rd party system, and write
integration tests for the real adapter to validate those assumptions.
This has saved my butt when a new version of the 3rd party system has
violated my assumptions.


I hope my question is clearer.
And I hope my answer is clearer.

- George



Eb


On Thu, Jul 11, 2013 at 4:16 PM, George Dinwiddie
<lists@...>wrote:

**


Eb,


On 7/11/13 2:28 PM, Eb wrote:
Hi everyone -

What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?
I wouldn't do that. I use adapters for third-party collaborators and
mock my adapters to verify behavior. I also write integration tests for
the adapter's interaction with the third-party.

Steve Freeman's advice is to never mock something you don't own. I've
only violated that advice when I needed to simulate error conditions
while testing my adapter.

- George
--
Want to speak at AgileDC October 8, 2013?
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------




--
blog:
twitter: @eikonne
Re: [TDD] Mocking collaborators that are third-party libraries

 

Eb,

On 7/11/13 5:35 PM, Eb wrote:
Thanks George.

I am following that advice also (already) so very good to get affirmation
of that.

However, I realize my question was not clear enough so continuing from your
answer, do you always verify behavior on mocked adaptors or are there
occasions where you don't? That is, you just mock them but don't verify.
I tend to use a state-based approach (aka "Detroit style") so I'm usually verifying the result of the behavior. Often my test doubles are simple fakes (data sources) or stubs (data sinks, but usually query-able by the test).

When I'm testing with a test-double adapter, I try to be cognizant of the assumptions I'm making about the 3rd party system, and write integration tests for the real adapter to validate those assumptions. This has saved my butt when a new version of the 3rd party system has violated my assumptions.

I hope my question is clearer.
And I hope my answer is clearer.

- George


Eb


On Thu, Jul 11, 2013 at 4:16 PM, George Dinwiddie
<lists@...>wrote:

**


Eb,


On 7/11/13 2:28 PM, Eb wrote:
Hi everyone -

What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?
I wouldn't do that. I use adapters for third-party collaborators and
mock my adapters to verify behavior. I also write integration tests for
the adapter's interaction with the third-party.

Steve Freeman's advice is to never mock something you don't own. I've
only violated that advice when I needed to simulate error conditions
while testing my adapter.

- George
--
Want to speak at AgileDC October 8, 2013?
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
Re: [TDD] Mocking collaborators that are third-party libraries

 

Thanks George.

I am following that advice also (already) so very good to get affirmation
of that.

However, I realize my question was not clear enough so continuing from your
answer, do you always verify behavior on mocked adaptors or are there
occasions where you don't? That is, you just mock them but don't verify.

I hope my question is clearer.

Eb


On Thu, Jul 11, 2013 at 4:16 PM, George Dinwiddie
<lists@...>wrote:

**


Eb,


On 7/11/13 2:28 PM, Eb wrote:
Hi everyone -

What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?
I wouldn't do that. I use adapters for third-party collaborators and
mock my adapters to verify behavior. I also write integration tests for
the adapter's interaction with the third-party.

Steve Freeman's advice is to never mock something you don't own. I've
only violated that advice when I needed to simulate error conditions
while testing my adapter.

- George

--
Want to speak at AgileDC October 8, 2013?
----------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------




--
blog:
twitter: @eikonne
Re: [TDD] Mocking collaborators that are third-party libraries

 

Eb,

On 7/11/13 2:28 PM, Eb wrote:
Hi everyone -

What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?
I wouldn't do that. I use adapters for third-party collaborators and mock my adapters to verify behavior. I also write integration tests for the adapter's interaction with the third-party.

Steve Freeman's advice is to never mock something you don't own. I've only violated that advice when I needed to simulate error conditions while testing my adapter.

- George

--
Want to speak at AgileDC October 8, 2013?
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
Mocking collaborators that are third-party libraries

 

Hi everyone -

What criteria do you use to determine if a collaborator that is a
third-party should be mocked and the test should verify that the
collaborator was indeed called when it was supposed to be?

Thanks.

Eb

--
blog:
twitter: @eikonne
Re: [TDD] Statics and caches and mocks oh my!

 

There is a practice called "bebugging" (not a typo) in which developers deliberately seed the program with known bugs. The presumption is that testers will find them at about the same rate as unknown bugs. When enough have been found, the testing is considered to be adequate. Assuming existing bug rates in the absence of bebugging can be unreliable - but only if you really do have a better way of doing things.

On Jun 30, 2013, at 5:57 AM, James Shaw <js102@...> wrote:

On 28 June 2013 20:24, Keith Ray <keith.ray@...> wrote:
On 2013 Jun 27, at 4:06 PM, David Burstin <david.burstin@...> wrote:

The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing!
Wow. I knew a programmer who was dinged by her manager because she wasn't creating enough bugs. They expected a certain number of bugs per some number of lines of code to be found in code-review and testing.
I remember reading that NASA projects would not be released until a
certain number of bugs had been found. This number was based on the
project size and compared against bug statistics gathered from
previous projects. Sadly, I can't find a URL to cite right now.


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

Yahoo! Groups Links


-----------------
Come read my webnovel, Take a Lemon <>,
and listen to the Misfile radio play <>!
Re: [TDD] Statics and caches and mocks oh my!

 

On 28 June 2013 20:24, Keith Ray <keith.ray@...> wrote:
On 2013 Jun 27, at 4:06 PM, David Burstin <david.burstin@...> wrote:

The standard policy is that for every 10 hours of
coding we need to allocate 3 hours of future defect fixing!
Wow. I knew a programmer who was dinged by her manager because she wasn't creating enough bugs. They expected a certain number of bugs per some number of lines of code to be found in code-review and testing.
I remember reading that NASA projects would not be released until a
certain number of bugs had been found. This number was based on the
project size and compared against bug statistics gathered from
previous projects. Sadly, I can't find a URL to cite right now.
Re: Statics and caches and mocks oh my!

 

--- Keith Ray <keith.ray@...> wrote:
Wow. I knew a programmer who was dinged by her manager because
she wasn't creating enough bugs. They expected a certain number
of bugs per some number of lines of code to be found in code-
review and testing.
That would, of course, inspire me to insert this gem every X number of lines:

System.exit(-1) // TODO: Find and remove this "bug" during code review.

.

.

OK; so I'm evil. >;->
901 - 920 of 36280