Re: Unit tests and parameter validation
Eb <[email protected]>
| Newsgroups | gmane.comp.programming.test-driven-development |
|---|---|
| Message-ID | <CANEY99ZtivWU+R9Gt70Q-pXVOOyUaRGzp3WoKCxCD2nipS3gSg@mail.gmail.com> |
Lior - Sure. Eb On Tue, Oct 15, 2013 at 4:16 PM, Lior Friedman <[email protected]> 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" <[email protected]> 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 <[email protected] >> > 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:* [email protected] [mailto: >>> [email protected]] *On Behalf Of *Colin Vipurs >>> *Sent:* 15 October 2013 18:52 >>> *To:* [email protected] >>> *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 <[email protected]> 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: http://eikonne.wordpress.com**** >>> >>> 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: http://eikonne.wordpress.com >> twitter: @eikonne >> >> > -- blog: http://eikonne.wordpress.com twitter: @eikonne