Re: Unit tests and parameter validation
Eb <[email protected]>
| Newsgroups | gmane.comp.programming.test-driven-development |
|---|---|
| Message-ID | <CANEY99YGjfKhz0PS=Xvzap6+80JdH-vSh6rvDR8ciPKw-tfRdw@mail.gmail.com> |
Exactly, bad habit! LOL. Thanks Adam. On Tue, Oct 15, 2013 at 8:33 PM, Adam Sroka <[email protected]> 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 <[email protected]> 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 >>> www.XProgramming.com <http://www.xprogramming.com> >>> 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: http://eikonne.wordpress.com twitter: @eikonne