Re: What I hate about *Unit frameworks.

It could, but it doesn't necessarily. The only time I have ever seen it
become a problem is when someone was doing something they shouldn't
irrespective of the fact that it was in a test. Also, it's less likely to
come up if you are actually test-driving and not trying to hack a test into
something you didn't build in a testable way.

Maybe I'm a bit oversensitive on this issue. It's just that I hear people
talk about monkey patching like it is an inherently bad idea and I want to
say, "Why is it that you adopted a dynamic language, again?"
 On May 3, 2013 1:14 PM, "George Dinwiddie" <[email protected]> wrote:

> **
>
>
> Adam,
>
> On 5/3/13 1:50 PM, Adam Sroka wrote:
> > Perl was my first professional language. I am not afraid of monkey
> > patching.
> >
> > A hammer is a useful tool. Please refrain from hitting yourself with it.
>
> Thanks for the admonition. I was just trying to explain how
> monkey-patching causes more interference between tests than mocks do.
>
> - George
>
> >
> >
> > On Thu, May 2, 2013 at 5:03 PM, George Dinwiddie <
> [email protected]>wrote:
> >
> >> **
> >>
> >>
> >> Adam,
> >>
> >>
> >> On 5/2/13 7:15 PM, Adam Sroka wrote:
> >>> Hi George:
> >>>
> >>> That makes sense, but you can do the same thing to yourself with mocks.
> >>> That's why you have to make sure you write microtests for both sides of
> >> the
> >>> relationship and cover the same conditions (I think J.B. calls them
> >>> "contract tests.")
> >>
> >> No, with monkey patching you're often messing up *library code* to the
> >> detriment of other tests.
> >>
> >>
> >>>
> >>> I only think monkey patching is bad when you violate the implied
> >> interface,
> >>> or when you go way down in the inheritance hierarchy and muck with
> things
> >>> that could have wide ranging effects (Both of which are smells in
> dynamic
> >>> languages anyway.) But, if you were actually doing TDD something would
> go
> >>> red when you did either of those things, right?
> >>
> >> Maybe. Or maybe your monkey patching makes other tests work, but the app
> >> doesn't when it's in production and the library hasn't been
> monkey-patched.
> >>
> >> - George
> >>
> >>
> >>>
> >>>
> >>> On Thu, May 2, 2013 at 7:46 AM, George Dinwiddie <
> >> [email protected]>wrote:
> >>>
> >>>> **
> >>
> >>>>
> >>>>
> >>>> Adam,
> >>>>
> >>>>
> >>>> On 5/1/13 11:25 PM, Adam Sroka wrote:
> >>>>> Maybe I'm just dense, but: what is it about this that is particular
> to
> >>>> TDD?
> >>>>> Seems to me that monkey patching without tests is *fuck all* more
> >>>> dangerous
> >>>>> than writing a test, making it pass in the simplest way possible, and
> >>>> then
> >>>>> improving the design. What am I missing???
> >>>>
> >>>> Monkey patching is a common method to create testing seams, even by
> >>>> people who would not use monkey patching in the deliverable system
> code.
> >>>> It's a quick-and-dirty way of mocking using the real objects.
> >>>>
> >>>> - George
> >>>>
> >>>>
> >>>>> On May 1, 2013 8:12 PM, "John Roth" <[email protected]> wrote:
> >>>>>
> >>>>>> **
> >>>>
> >>>>>>
> >>>>>>
> >>>>>> On 5/1/13 7:12 AM, David Stanek wrote:
> >>>>>>>
> >>>>>>> On Wed, May 1, 2013 at 6:27 AM, Angel Java Lopez
> >>>>>>> <[email protected] <mailto:ajlopez2000%40gmail.com>>wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> John, usually I don't find the case "this test corrupts that
> test",
> >>>>>>> and I
> >>>>>>>> wrote thousands of tests.
> >>>>>>>>
> >>>>>>>> Any example/case?
> >>>>>>>
> >>>>>>> I've seen this in Python tests where developers monkey-patch things
> >> and
> >>>>>>> forget to set them back or otherwise muck with global state. This
> has
> >>>>>> been
> >>>>>>> the result of design issues.
> >>>>>>>
> >>>>>>
> >>>>>> Snort. This is a continuing issue for the Python developers as well.
> >>>>>>
> >>>>>> John Roth
>
> --
> ----------------------------------------------------------
> * George Dinwiddie * http://blog.gdinwiddie.com
> Software Development http://www.idiacomputing.com
> Consultant and Coach http://www.agilemaryland.org
> ----------------------------------------------------------
>
>  
>


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



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

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/testdrivendevelopment/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/testdrivendevelopment/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/