|
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.
|
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.
|
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.
|
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
|
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
|
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.
|
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
|
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
|
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:
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
Keith Ray wrote: 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. In that case you just got pwned by a framework. Ouch. Adding to what I said before, the in/out view blurs if you create thin verticals, which you should, but even then I prefer going from the Big Test (which really isn't that big at first). Michal
|
