Re: [TDD] Unit tests and parameter validation
Personally I don't go outside-in or inside-out, but I use one of two heuristics that work well for me:
1) What?is the customer trying to accomplish? How would I know if it did that??
2) What is the essence of the problem that I don't yet understand? How would I learn about that??
I pick one of those two, write?a test for it, and see where it leads me. Then, after a reasonable amount of time -- from a few minutes to maybe an hour -- I take a break and talk with my pair?about how we?want to go at it next. I repeat that process until it's time for a meeting or a beer.?
On Friday, October 18, 2013, Adam Sroka wrote: I've seen Ward Cunningham and Kent Beck, both widely regarded as the inventors of TDD, code, and neither of them followed strict?"outside-in" semantics. It must at least be possible that you could create a simple design without doing that.?
On Friday, October 18, 2013, Michal Svoboda wrote:
?
Eb wrote:
> Curious how if this changes if one develops inside out.
Your probability increases that you develop the wrong thing. :)
On the original point, if your guards are mostly about null, then you
can annotate your stuff with @Nonnull (or similar if your language
supports it). This then makes the contract more like a strong type
system and violations can be likely caught by static analysis tools.
Michal
|
Re: [TDD] Unit tests and parameter validation
I've seen Ward Cunningham and Kent Beck, both widely regarded as the inventors of TDD, code, and neither of them followed strict?"outside-in" semantics. It must at least be possible that you could create a simple design without doing that.?
toggle quoted message
Show quoted text
On Friday, October 18, 2013, Michal Svoboda wrote:
?
Eb wrote:
> Curious how if this changes if one develops inside out.
Your probability increases that you develop the wrong thing. :)
On the original point, if your guards are mostly about null, then you
can annotate your stuff with @Nonnull (or similar if your language
supports it). This then makes the contract more like a strong type
system and violations can be likely caught by static analysis tools.
Michal
|
Re: [TDD] Unit tests and parameter validation
Eb, On Oct 18, 2013, at 2:34 PM, Eb < amaeze@...> wrote: Keith gave an example of such a scenario. The outside object doesn't necessarily meet the needs of the inside object. ?I personally, rarely get expectations right (being complete) the first - maybe there is a programming practice that I need to incorporate. ?Maybe going outside in reduces the number of iterations of such manner but I've definitely "discovered" that something needs to be changed to meet expectations.
Do you mean the outside object may need to provide additional parameters to the inside object?
Keith's example doesn't seem very outside-in to me, in the sense that the inside object seems to already exist, which is more like inside out ¡
Probably doesn't matter ...
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Re: [TDD] Unit tests and parameter validation
Ron -
Keith gave an example of such a scenario. The outside object doesn't necessarily meet the needs of the inside object. ?I personally, rarely get expectations right (being complete) the first - maybe there is a programming practice that I need to incorporate. ?Maybe going outside in reduces the number of iterations of such manner but I've definitely "discovered" that something needs to be changed to meet expectations.
Eb
On Fri, Oct 18, 2013 at 2:16 PM, Ron Jeffries <ronjeffries@...> wrote:
?
Eb, On Oct 18, 2013, at 1:52 PM, Eb < amaeze@...> wrote: Ok. But I've experienced that developing outside in also.
Really? You developed some outside object, and then went to develop an inside object, and it didn't meet the needs of the object, already existing, that was calling it??
How did that happen?
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
-- blog:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
If "outside" is GUI/user and "inside" is using a framework or database, then there can be a mis-match, when you find out the database needs info not yet provided by the GUI/user, or that the framework requires asynchronous behavior when the GUI assumes simple synchronous behavior.
--
C. Keith Ray
* 650-533-6535
*?
*?
toggle quoted message
Show quoted text
?
Eb, On Oct 18, 2013, at 1:52 PM, Eb < amaeze@...> wrote: Ok. But I've experienced that developing outside in also.
Really? You developed some outside object, and then went to develop an inside object, and it didn't meet the needs of the object, already existing, that was calling it??
How did that happen?
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Re: [TDD] Unit tests and parameter validation
Eb, On Oct 18, 2013, at 1:52 PM, Eb < amaeze@...> wrote: Ok. But I've experienced that developing outside in also.
Really? You developed some outside object, and then went to develop an inside object, and it didn't meet the needs of the object, already existing, that was calling it??
How did that happen?
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Re: [TDD] Unit tests and parameter validation
Ok. But I've experienced that developing outside in also.
On Fri, Oct 18, 2013 at 1:50 PM, Matteo Vaccari <vaccari@...> wrote:
?
Simply because you are assuming, as you develop your "inside" objects, that they will provide the right services to the "outside" objects that you will develop later. ?They might, or they might not, in which case you'll have to do some rework.
-- blog:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
Simply because you are assuming, as you develop your "inside" objects, that they will provide the right services to the "outside" objects that you will develop later. ?They might, or they might not, in which case you'll have to do some rework.
On Fri, Oct 18, 2013 at 7:44 PM, Eb <amaeze@...> wrote:
|
Re: [TDD] Unit tests and parameter validation
toggle quoted message
Show quoted text
On Fri, Oct 18, 2013 at 1:36 PM, Michal Svoboda <pht@...> wrote:
?
Eb wrote:
> Curious how if this changes if one develops inside out.
Your probability increases that you develop the wrong thing. :)
On the original point, if your guards are mostly about null, then you
can annotate your stuff with @Nonnull (or similar if your language
supports it). This then makes the contract more like a strong type
system and violations can be likely caught by static analysis tools.
Michal
-- blog:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
Eb wrote: Curious how if this changes if one develops inside out. Your probability increases that you develop the wrong thing. :) On the original point, if your guards are mostly about null, then you can annotate your stuff with @Nonnull (or similar if your language supports it). This then makes the contract more like a strong type system and violations can be likely caught by static analysis tools. Michal
|
Re: [TDD] Unit tests and parameter validation
I believe it was this advice (from Ron) that I read many, many years ago (fairly sure it was on this list too) that led me to drop doing defensive coding and I've never looked back. ?Not only does it lead to less code overall but opened me up to focussing on contracts and ensuring they are adhered to.
On Wed, Oct 16, 2013 at 12:42 AM, Ron Jeffries <ronjeffries@...> wrote:
?
Eb, On Oct 15, 2013, at 12:03 PM, Eb < amaeze@...> 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
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.
-- 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
Exactly, bad habit! LOL.
Thanks Adam.
On Tue, Oct 15, 2013 at 8:33 PM, Adam Sroka <adam.sroka@...> 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 <amaeze@...> 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
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:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
Thanks Ron.
It sounds like you test/develop outside in. ?Is my inference wrong? ?Curious how if this changes if one develops inside out. ?Probably the statement would that be we will be writing tests for the code that calls the code currently being developed.
Definitely, this is defensive coding.
Eb
On Tue, Oct 15, 2013 at 7:42 PM, Ron Jeffries <ronjeffries@...> wrote:
?
Eb, On Oct 15, 2013, at 12:03 PM, Eb < amaeze@...> 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
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:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
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
toggle quoted message
Show quoted text
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 <amaeze@...> 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
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.
|
Re: [TDD] Unit tests and parameter validation
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.?
toggle quoted message
Show quoted text
On Tuesday, October 15, 2013, Ron Jeffries wrote:
?
Eb, On Oct 15, 2013, at 12:03 PM, Eb < amaeze@...> 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
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.
|
Re: [TDD] Unit tests and parameter validation
Eb, On Oct 15, 2013, at 12:03 PM, Eb < amaeze@...> 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
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.
|
Re: [TDD] Unit tests and parameter validation
toggle quoted message
Show quoted text
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: - Have your test look for the exception that will be thrown by the code
- Have your code validate the parameters to prevent an exception from being thrown?
- 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.
-- blog:
twitter: @eikonne
|
Re: [TDD] Unit tests and parameter validation
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
|
Re: [TDD] Unit tests and parameter validation
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
?
Donald -
If a test passes in the wrong input and fails initially, I see 3 general ways of getting the test to pass: - Have your test look for the exception that will be thrown by the code
- Have your code validate the parameters to prevent an exception from being thrown?
- 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.
|
Re: [TDD] Unit tests and parameter validation
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
|
