Loading ...
Sorry, an error occurred while loading the content.

Re: Stubs, Fakes, and Mocks

Expand Messages
  • Matt
    Vlad, Thanks for the blog entry (and for giving us a hint of the contents when you posted in here!) I had a question about this: You may have the
    Message 1 of 22 , Dec 30, 2007
    • 0 Attachment
      Vlad,

      Thanks for the blog entry (and for giving us a hint of the contents when
      you posted in here!)

      I had a question about this:

      <quote>

      You may have the illusion that using mocks is letting you design your
      code top-down, i.e. you can write a test for a high level function
      before you implement any of the lower-level code it depends on, but you
      are also accumulating technical debt: You may have to wait a while
      before finding out whether your application actually works.

      </quote>

      Isn't it true that "bottom up" coding requires you to wait a while
      before finding out if your application really works? I mean, until you
      can run the application, you really don't know whether it works or not.
      If all you have is your bottom layer working... well you can't really
      run the app yet... at least not with the feature in progress running.
      So in that sense, aren't you accumulating "technical debt" (in the
      context in which you used the term) whether you do bottom-up or
      top-down?

      The advantage I have found with top-down is that I can quickly see what
      the client needs (the client might just be a presenter layer) because I
      know what the inputs and outputs are supposed to be at the top. Then I
      can work my way down and *only* write what it takes to satisfy those
      requirements. Mocks are very useful in working in this fashion... but
      they are easily abused too!

      Thanks,

      Matt
    • Steve Howell
      ... The application doesn t really *work* until the bottom and the top are implemented, but I agree that implementing only the top can probably facilitate
      Message 2 of 22 , Dec 30, 2007
      • 0 Attachment
        --- Matt <maswaffer@...> wrote:

        >
        > Isn't it true that "bottom up" coding requires you
        > to wait a while
        > before finding out if your application really works?

        The application doesn't really *work* until the bottom
        and the top are implemented, but I agree that
        implementing only the top can probably facilitate
        getting useful feedback from the customers.

        > I mean, until you
        > can run the application, you really don't know
        > whether it works or not.
        > If all you have is your bottom layer working... well
        > you can't really
        > run the app yet... at least not with the feature in
        > progress running.
        > So in that sense, aren't you accumulating "technical
        > debt" (in the
        > context in which you used the term) whether you do
        > bottom-up or
        > top-down?
        >

        If the bottom-up design is mostly valid, then your
        only tech debt will be refactoring it a bit as you
        start to code the higher layers. Also, if the bottom
        layers are carefully implemented and reasonably fast,
        you won't need to mock them.

        If you're test-driving the bottom layers, then you're
        still working top-down at some level, of course.

        > The advantage I have found with top-down is that I
        > can quickly see what
        > the client needs (the client might just be a
        > presenter layer) because I
        > know what the inputs and outputs are supposed to be
        > at the top. Then I
        > can work my way down and *only* write what it takes
        > to satisfy those
        > requirements. Mocks are very useful in working in
        > this fashion... but
        > they are easily abused too!
        >

        Agreed.

        I actually tend to bounce back-and-forth between
        bottom-up and top-down. You can often slice a problem
        vertically instead of horizontally. If your bottom
        layer is akin to a model, and the top layer is akin to
        a controller, then you might start by implementing a
        read-only interface for both, and in some cases just
        the read-only part might even have customer value.



        ____________________________________________________________________________________
        Never miss a thing. Make Yahoo your home page.
        http://www.yahoo.com/r/hs
      • George Dinwiddie
        ... Back in the 1980s, P.J. Plauger wrote a column in Computer Language magazine called Programming on Purpose (later reworked into a book). He did a series
        Message 3 of 22 , Dec 31, 2007
        • 0 Attachment
          Matt wrote:
          > Isn't it true that "bottom up" coding requires you to wait a while
          > before finding out if your application really works? I mean, until you
          > can run the application, you really don't know whether it works or not.
          > If all you have is your bottom layer working... well you can't really
          > run the app yet... at least not with the feature in progress running.
          > So in that sense, aren't you accumulating "technical debt" (in the
          > context in which you used the term) whether you do bottom-up or
          > top-down?
          >
          > The advantage I have found with top-down is that I can quickly see what
          > the client needs (the client might just be a presenter layer) because I
          > know what the inputs and outputs are supposed to be at the top. Then I
          > can work my way down and *only* write what it takes to satisfy those
          > requirements. Mocks are very useful in working in this fashion... but
          > they are easily abused too!

          Back in the 1980s, P.J. Plauger wrote a column in Computer Language
          magazine called Programming on Purpose (later reworked into a book). He
          did a series of columns on Top-Down, Bottom-Up, Outside-In, Inside-Out,
          and perhaps several other approaches to developing software. In some
          sense, they're stylistic. In another, they're a reflection of how you
          think about the problem.

          Matt, like you, I generally find that Top-Down helps me focus on the
          goal--except when it doesn't. Sometimes, especially when dealing with
          embedded systems, Bottom-Up lets me define the primitives appropriate to
          the hardware and then build more and more abstract layers on top, until
          it's obvious what the Top looks like. Or, when the primitives take a
          certain definiteness, jump to the top level and program down to
          them--Outside-In. Then there are times when I'm only sure on one thing,
          perhaps an algorithm, so I start with that and push out in all
          directions--Inside-Out.

          The point is that any of these may be the best for a given person in a
          given situation, but none of them are universally best.

          And none of them imply mocks or not-mocks. That's an independent choice.

          - George

          --
          ----------------------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Matt
          George, Thanks for the insight. It s reassuring to know that I am not the *only* one that bounces around from one way to the other! I prefer top-down but
          Message 4 of 22 , Dec 31, 2007
          • 0 Attachment
            George,

            Thanks for the insight. It's reassuring to know that I am not the
            *only* one that bounces around from one way to the other! I prefer
            top-down but like you said... there are times when it just works better
            to use some other method.

            It is true that you can do top-down without mocks but in my experience
            it is easier to do that. Any other methods that you would suggest as
            interesting alternatives?

            Matt


            --- In extremeprogramming@yahoogroups.com, George Dinwiddie <lists@...>
            wrote:
            >
            > Matt, like you, I generally find that Top-Down helps me focus on the
            > goal--except when it doesn't. Sometimes, especially when dealing with
            > embedded systems, Bottom-Up lets me define the primitives appropriate
            to
            > the hardware and then build more and more abstract layers on top,
            until
            > it's obvious what the Top looks like. Or, when the primitives take a
            > certain definiteness, jump to the top level and program down to
            > them--Outside-In. Then there are times when I'm only sure on one
            thing,
            > perhaps an algorithm, so I start with that and push out in all
            > directions--Inside-Out.
            >
            > The point is that any of these may be the best for a given person in a
            > given situation, but none of them are universally best.
            >
            > And none of them imply mocks or not-mocks. That's an independent
            choice.
            >
            > - George
            >
          • George Dinwiddie
            ... I ll generally do top-down without mocks, building the domain model as I go. I often won t use a fake until I get to a boundary interfacing with some
            Message 5 of 22 , Dec 31, 2007
            • 0 Attachment
              Matt wrote:
              > It is true that you can do top-down without mocks but in my experience
              > it is easier to do that. Any other methods that you would suggest as
              > interesting alternatives?

              I'll generally do top-down without mocks, building the domain model as I
              go. I often won't use a fake until I get to a boundary interfacing with
              some other system, notably the persistence layer.

              When working with legacy code, I'll often come across some chunk of the
              domain model that's hard to instantiate and unimportant for the test at
              hand. Then I'll fake out that bit. One of the advantages of the way I
              work in greenfield dev (as described above) is that hard-to-instantiate
              chunks of domain model don't tend to occur.

              In all of this I tend to use fakes and stubs and spys, rather than
              mocks. I was in love with mocks when I first discovered them, but now I
              can't remember why.

              - George

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            • Lior Friedman
              v :* {behavior:url(#default#VML);}o :* {behavior:url(#default#VML);}w :* {behavior:url(#default#VML);}..shape
              Message 6 of 22 , Dec 31, 2007
              • 0 Attachment
                v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}..shape {behavior:url(#default#VML);}st1\:*{behavior:url(#default#ieooui) }
                Hi all,

                Actually, anotheralternative which comes to mind and I feel was somewhat left out is the "End-To-End".

                (Most likely causeeveryone took it for granted)



                From my small experience,it doesn’t really matter if you do Top-Down or Bottom-Up but it isimportant that you do End-To-End.







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


                From: extremeprogramming@yahoogroups.com [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Matt
                Sent: Monday, December 31, 20075:45 PM
                To: extremeprogramming@yahoogroups.com
                Subject: [XP] Re: Stubs, Fakes,and Mocks


                George,

                Thanks for the insight. It's reassuring to know that I am not the
                *only* one that bounces around from one way to the other! I prefer
                top-down but like you said... there are times when it just works better
                to use some other method.

                It is true that you can do top-down without mocks but in my experience
                it is easier to do that. Any other methods that you would suggest as
                interesting alternatives?

                Matt









                ---------------------------------
                Looking for last minute shopping deals? Find them fast with Yahoo! Search.

                [Non-text portions of this message have been removed]
              • Vlad
                George, You make a good point. It s not just a matter of top-down vs. bottom-up. My personal preference is to start with the domain logic in a bottom-up
                Message 7 of 22 , Dec 31, 2007
                • 0 Attachment
                  George,

                  You make a good point. It's not just a matter of top-down vs.
                  bottom-up. My personal preference is to start with the
                  domain logic in a bottom-up fashion. If one thinks of persistence
                  as the bottom-most layer in a piece of software, then I don't
                  technically start bottom-up; I am willing to simply hold my
                  objects in memory and worry about persisting them later.
                  I work my way up to the user interface, and finally I plug
                  in persistence. My "justification" for this approach is that I
                  want as much logic to be in the domain code as possible and for
                  the ui code and persistence code to be as "thin" as possible.
                  Of course I don't develop *all* of my domain code at once. I write
                  enough to fulfill a story, then finish off the ui and persistence
                  aspects before I continue to another story: My approach is
                  therefore to develop in vertical (end-to-end) "slices "
                  rather than in horizontal "pancakes" (finish all the domain
                  code, the all the ui code, then all the persistence code).

                  My understanding of "mock-driven" development is that one
                  tends to start development at the highest level possible to
                  "discover" the entry-point interface, and then one delves
                  into the logic of the application one level at a time,
                  mocking out the level immediately below.

                  My personal issue with that is that it's hard to tell
                  whether the layers of code one is writing will really work
                  out. I also have a feeling that refactoring can become
                  harder to do. For example it's not unusual for me to
                  write some code as "if ... else..." and then once a
                  test passes to refactor such conditional logic into
                  one place if it's being duplicated. I personally
                  like the sense of stability I get from writing a
                  piece of code to to perform a needed task and then to
                  start using that code as a building block for something
                  else. I do recognize, especially after reading some of
                  the posts here, that there's a pretty strong element of
                  personal style in play here.

                  I don't know if I've had the experience of discovering that
                  my lower-level building blocks were completely wrong
                  as I started to reach the higher-level code. I do refactor
                  as I go along so that probably mitigates this kind of
                  potential pitfall at least to some extent.

                  --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                  <lists@...> wrote:
                  > Back in the 1980s, P.J. Plauger wrote a column in Computer Language
                  > magazine called Programming on Purpose (later reworked into a book).
                  He
                  > did a series of columns on Top-Down, Bottom-Up, Outside-In, Inside-Out,
                  > and perhaps several other approaches to developing software. In some
                  > sense, they're stylistic. In another, they're a reflection of how you
                  > think about the problem.
                  >
                  > Matt, like you, I generally find that Top-Down helps me focus on the
                  > goal--except when it doesn't. Sometimes, especially when dealing with
                  > embedded systems, Bottom-Up lets me define the primitives
                  appropriate to
                  > the hardware and then build more and more abstract layers on top, until
                  > it's obvious what the Top looks like. Or, when the primitives take a
                  > certain definiteness, jump to the top level and program down to
                  > them--Outside-In. Then there are times when I'm only sure on one
                  thing,
                  > perhaps an algorithm, so I start with that and push out in all
                  > directions--Inside-Out.
                  >
                  > The point is that any of these may be the best for a given person in a
                  > given situation, but none of them are universally best.
                  >
                  > And none of them imply mocks or not-mocks. That's an independent
                  choice.
                  >
                  > - George
                  >
                  > --
                  > ----------------------------------------------------------------------
                  > * George Dinwiddie * http://blog.gdinwiddie.com
                  > Software Development http://www.idiacomputing.com
                  > Consultant and Coach http://www.agilemaryland.org
                  > ----------------------------------------------------------------------
                  >
                • Boysenberry Payne
                  Doing mostly web oriented development I tend to mock/fake the requests and work at satisfying them first. I m not sure if this would be considered a top down
                  Message 8 of 22 , Dec 31, 2007
                  • 0 Attachment
                    Doing mostly web oriented development I tend to mock/fake the
                    requests and work at satisfying them first.

                    I'm not sure if this would be considered a top down approach or not.
                    I guess its working from the outside-in. But really to me its seems
                    from bottom-up or inside out. I say this because what it allows
                    me to do is work on the logic that satisfies the request first.

                    Once I've found out whether or not I have the the supportive logic in
                    place
                    I either write more tests, testing the supportive logic or I complete
                    the
                    original tests for the request.

                    Would this be top-down or bottom-up?


                    On Dec 31, 2007, at 12:19 PM, Vlad wrote:

                    > George,
                    >
                    > You make a good point. It's not just a matter of top-down vs.
                    > bottom-up. My personal preference is to start with the
                    > domain logic in a bottom-up fashion. If one thinks of persistence
                    > as the bottom-most layer in a piece of software, then I don't
                    > technically start bottom-up; I am willing to simply hold my
                    > objects in memory and worry about persisting them later.
                    > I work my way up to the user interface, and finally I plug
                    > in persistence. My "justification" for this approach is that I
                    > want as much logic to be in the domain code as possible and for
                    > the ui code and persistence code to be as "thin" as possible.
                    > Of course I don't develop *all* of my domain code at once. I write
                    > enough to fulfill a story, then finish off the ui and persistence
                    > aspects before I continue to another story: My approach is
                    > therefore to develop in vertical (end-to-end) "slices "
                    > rather than in horizontal "pancakes" (finish all the domain
                    > code, the all the ui code, then all the persistence code).
                    >
                    > My understanding of "mock-driven" development is that one
                    > tends to start development at the highest level possible to
                    > "discover" the entry-point interface, and then one delves
                    > into the logic of the application one level at a time,
                    > mocking out the level immediately below.
                    >
                    > My personal issue with that is that it's hard to tell
                    > whether the layers of code one is writing will really work
                    > out. I also have a feeling that refactoring can become
                    > harder to do. For example it's not unusual for me to
                    > write some code as "if ... else..." and then once a
                    > test passes to refactor such conditional logic into
                    > one place if it's being duplicated. I personally
                    > like the sense of stability I get from writing a
                    > piece of code to to perform a needed task and then to
                    > start using that code as a building block for something
                    > else. I do recognize, especially after reading some of
                    > the posts here, that there's a pretty strong element of
                    > personal style in play here.
                    >
                    > I don't know if I've had the experience of discovering that
                    > my lower-level building blocks were completely wrong
                    > as I started to reach the higher-level code. I do refactor
                    > as I go along so that probably mitigates this kind of
                    > potential pitfall at least to some extent.
                    >
                    > --- In extremeprogramming@yahoogroups.com, George Dinwiddie
                    > <lists@...> wrote:
                    > > Back in the 1980s, P.J. Plauger wrote a column in Computer Language
                    > > magazine called Programming on Purpose (later reworked into a book).
                    > He
                    > > did a series of columns on Top-Down, Bottom-Up, Outside-In,
                    > Inside-Out,
                    > > and perhaps several other approaches to developing software. In some
                    > > sense, they're stylistic. In another, they're a reflection of how
                    > you
                    > > think about the problem.
                    > >
                    > > Matt, like you, I generally find that Top-Down helps me focus on the
                    > > goal--except when it doesn't. Sometimes, especially when dealing
                    > with
                    > > embedded systems, Bottom-Up lets me define the primitives
                    > appropriate to
                    > > the hardware and then build more and more abstract layers on top,
                    > until
                    > > it's obvious what the Top looks like. Or, when the primitives take a
                    > > certain definiteness, jump to the top level and program down to
                    > > them--Outside-In. Then there are times when I'm only sure on one
                    > thing,
                    > > perhaps an algorithm, so I start with that and push out in all
                    > > directions--Inside-Out.
                    > >
                    > > The point is that any of these may be the best for a given person
                    > in a
                    > > given situation, but none of them are universally best.
                    > >
                    > > And none of them imply mocks or not-mocks. That's an independent
                    > choice.
                    > >
                    > > - George
                    > >
                    > > --
                    > > ----------------------------------------------------------
                    > > * 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]
                  • Steve Freeman
                    ... Yes, but you don t implement an entire level at a time, but a series of end-to-end slices. ... Personally, I ve stopped trying to write bottom-up layers in
                    Message 9 of 22 , Jan 1, 2008
                    • 0 Attachment
                      On 31 Dec 2007, at 19:19, Vlad wrote:
                      > My understanding of "mock-driven" development is that one
                      > tends to start development at the highest level possible to
                      > "discover" the entry-point interface, and then one delves
                      > into the logic of the application one level at a time,
                      > mocking out the level immediately below.
                      >
                      Yes, but you don't implement an entire level at a time, but a series
                      of end-to-end slices.

                      > I don't know if I've had the experience of discovering that
                      > my lower-level building blocks were completely wrong
                      > as I started to reach the higher-level code. I do refactor
                      > as I go along so that probably mitigates this kind of
                      > potential pitfall at least to some extent.
                      >
                      Personally, I've stopped trying to write bottom-up layers in
                      isolation because I got tired of building stuff I didn't want. It's
                      not so much code that's completely wrong as all the little dead-ends
                      and unused pieces.

                      S.

                      Steve Freeman
                      http://www.mockobjects.com

                      Winner of the Agile Alliance Gordon Pask award 2006
                    • Steve Freeman
                      ... Of course, it s a matter of degree and mind-set. People build working systems bottom-up all the time. My experience is that I usually spend too much time
                      Message 10 of 22 , Jan 1, 2008
                      • 0 Attachment
                        On 31 Dec 2007, at 03:16, Steve Howell wrote:
                        > The discussion on the blog so far on the page deals
                        > with bottom-up vs. top-down. I don't exactly
                        > understand the poster Steven's point that building
                        > bottom-up leads to creating the wrong objects. That
                        > doesn't resonate with any experiences that I've had so
                        > far.
                        >

                        Of course, it's a matter of degree and mind-set. People build working
                        systems bottom-up all the time. My experience is that I usually spend
                        too much time writing speculative code that turns out not to be quite
                        right or used. Of course, if you're developing incrementally then
                        it's hard to stray too far from the path.

                        A more interesting difference is I find that top-down helps me think
                        about a service in terms of its clients, what they need from the
                        world, rather than its provider, what it might usefully do. I find
                        the result tends to be more expressive of whichever domain I'm in at
                        the time.

                        S.

                        Steve Freeman
                        http://www.mockobjects.com

                        Winner of the Agile Alliance Gordon Pask award 2006
                      • Steve Howell
                        ... Ok, makes sense. In this case, do you tend to use the mocks as scaffolding to be thrown away later, or do you keep the mocks around even after you ve
                        Message 11 of 22 , Jan 1, 2008
                        • 0 Attachment
                          --- Steve Freeman <smgfreeman@...> wrote:

                          > On 31 Dec 2007, at 03:16, Steve Howell wrote:
                          > > The discussion on the blog so far on the page
                          > deals
                          > > with bottom-up vs. top-down. I don't exactly
                          > > understand the poster Steven's point that building
                          > > bottom-up leads to creating the wrong objects.
                          > That
                          > > doesn't resonate with any experiences that I've
                          > had so
                          > > far.
                          > >
                          >
                          > Of course, it's a matter of degree and mind-set.
                          > People build working
                          > systems bottom-up all the time. My experience is
                          > that I usually spend
                          > too much time writing speculative code that turns
                          > out not to be quite
                          > right or used. Of course, if you're developing
                          > incrementally then
                          > it's hard to stray too far from the path.
                          >
                          > A more interesting difference is I find that
                          > top-down helps me think
                          > about a service in terms of its clients, what they
                          > need from the
                          > world, rather than its provider, what it might
                          > usefully do. I find
                          > the result tends to be more expressive of whichever
                          > domain I'm in at
                          > the time.
                          >

                          Ok, makes sense. In this case, do you tend to use the
                          mocks as scaffolding to be thrown away later, or do
                          you keep the mocks around even after you've gotten
                          around to implementing the "provider" layers (assuming
                          they're reasonably fast)?




                          ____________________________________________________________________________________
                          Looking for last minute shopping deals?
                          Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
                        • J. B. Rainsberger
                          ... I find it hard to express what I want to express in a way that doesn t risk Vlad being upset with me, so I throw myself on your mercy and beg you to
                          Message 12 of 22 , Jan 1, 2008
                          • 0 Attachment
                            On Dec 30, 2007, at 18:07 , Vlad wrote:
                            > This blog entry is my attempt to explain the different kinds test-only
                            > objects that can be substituted for the real thing in automated tests:
                            > Stubs, Fakes, and Mocks. It can be easy to get confused, so I hope
                            > this entry helps!
                            >
                            > http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html
                            >
                            I find it hard to express what I want to express in a way that doesn't
                            risk Vlad being upset with me, so I throw myself on your mercy and beg
                            you to interpret me generously.

                            Is it a failing of ours as leaders in this arena that so many people
                            find it necessary to re-explain this? or is it merely a consequence of
                            the vastness of the internet?

                            Vlad, please understand me, I haven't read your article, so I'm not
                            judging its quality, but I see one of these every month or so, and I
                            wonder why so many people find it necessary to go over such well-worn
                            ground. I'm not complaining, but rather seeking to understand.
                            ----
                            J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                            Your guide to software craftsmanship
                            JUnit Recipes: Practical Methods for Programmer Testing
                            2005 Gordon Pask Award for contribution Agile Software Practice
                          • Steve Howell
                            ... I would venture neither. The best way to deepen your understanding of an important topic is to publish your own interpretation of multiple sources and
                            Message 13 of 22 , Jan 1, 2008
                            • 0 Attachment
                              --- "J. B. Rainsberger" <jbrains762@...> wrote:
                              > Is it a failing of ours as leaders in this arena
                              > that so many people
                              > find it necessary to re-explain this? or is it
                              > merely a consequence of
                              > the vastness of the internet?
                              >

                              I would venture neither. The best way to deepen your
                              understanding of an important topic is to publish your
                              own interpretation of multiple sources and have it
                              reviewed. At least that's what my professors told me.

                              Vlad referenced Martin Fowler in the blog FWIW:

                              http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html




                              ____________________________________________________________________________________
                              Never miss a thing. Make Yahoo your home page.
                              http://www.yahoo.com/r/hs
                            • Ron Jeffries
                              ... Well, not having read it, we risk the possibility that, at last, someone has explained the topic /well/. I write things, first to understand them, then to
                              Message 14 of 22 , Jan 2, 2008
                              • 0 Attachment
                                Hello, J.. On Tuesday, January 1, 2008, at 9:51:56 PM, you wrote:

                                > Vlad, please understand me, I haven't read your article, so I'm not
                                > judging its quality, but I see one of these every month or so, and I
                                > wonder why so many people find it necessary to go over such well-worn
                                > ground. I'm not complaining, but rather seeking to understand.

                                Well, not having read it, we risk the possibility that, at last,
                                someone has explained the topic /well/.

                                I write things, first to understand them, then to share them. I
                                write things differently all the time in hopes that one of the
                                writings will help someone else to gain an understanding they didn't
                                previously have.

                                Is there a definitive and clear write up of this topic which, if
                                only all would read it, would enlighten us all and give us all the
                                same understanding? Based on what I have read so far about these
                                items, I'd like to know what it is, to read it, and to have everyone
                                else read it also.

                                But my guess is that the ground may be well worn, but that it is not
                                all that well understood by all who tread it.

                                Ron Jeffries
                                www.XProgramming.com
                                Fear is the mindkiller. --Bene Gesserit Litany Against Fear
                              • Vlad
                                My goal was to explain the differences in a way that I hoped would be as intuitive as possible (i.e. informal and minus pompous language) illustrated with
                                Message 15 of 22 , Jan 2, 2008
                                • 0 Attachment
                                  My goal was to explain the differences in a way that I hoped would be
                                  as intuitive as possible (i.e. informal and minus pompous language)
                                  illustrated with several straightforward but practical examples. I
                                  have also added the following links to other material on the subject.

                                  http://en.wikipedia.org/wiki/Mock_object
                                  href="http://www.c2.com/cgi/wiki?MockObject
                                  href="http://xunitpatterns.com/Test%20Double.html
                                  href="http://martinfowler.com/articles/mocksArentStubs.html
                                  href="http://langrsoft.com/articles/mocking.shtml

                                  My intent was also to offer my personal sense of when these different
                                  kinds of test-only objects (aka test-doubles) should and should not be
                                  used. If somebody offers corrections to my blog entry or additional
                                  helpful links, I'll happily incorporate them.

                                  Based on what I was able to find with some searching online, I was
                                  hoping to fill a small but helpful niche in the mock-objects/tdd
                                  landscape.

                                  --- In extremeprogramming@yahoogroups.com, "J. B. Rainsberger"
                                  <jbrains762@...> wrote:
                                  > Is it a failing of ours as leaders in this arena that so many people
                                  > find it necessary to re-explain this? or is it merely a consequence of
                                  > the vastness of the internet?
                                • J. B. Rainsberger
                                  ... OK. I buy that. Thanks. ... J. B. (Joe) Rainsberger :: http://www.jbrains.ca Your guide to software craftsmanship JUnit Recipes: Practical Methods for
                                  Message 16 of 22 , Jan 2, 2008
                                  • 0 Attachment
                                    On Jan 1, 2008, at 21:00 , Steve Howell wrote:
                                    > --- "J. B. Rainsberger" <jbrains762@...> wrote:
                                    > > Is it a failing of ours as leaders in this arena
                                    > > that so many people
                                    > > find it necessary to re-explain this? or is it
                                    > > merely a consequence of
                                    > > the vastness of the internet?
                                    > >
                                    >
                                    > I would venture neither. The best way to deepen your
                                    > understanding of an important topic is to publish your
                                    > own interpretation of multiple sources and have it
                                    > reviewed. At least that's what my professors told me.
                                    >
                                    > Vlad referenced Martin Fowler in the blog FWIW:
                                    >
                                    > http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html
                                    >
                                    OK. I buy that. Thanks.
                                    ----
                                    J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                    Your guide to software craftsmanship
                                    JUnit Recipes: Practical Methods for Programmer Testing
                                    2005 Gordon Pask Award for contribution Agile Software Practice
                                  • J. B. Rainsberger
                                    ... For sure, I buy that. Thanks. ... J. B. (Joe) Rainsberger :: http://www.jbrains.ca Your guide to software craftsmanship JUnit Recipes: Practical Methods
                                    Message 17 of 22 , Jan 2, 2008
                                    • 0 Attachment
                                      On Jan 2, 2008, at 06:46 , Ron Jeffries wrote:
                                      > But my guess is that the ground may be well worn, but that it is not
                                      > all that well understood by all who tread it.
                                      >
                                      For sure, I buy that. Thanks.
                                      ----
                                      J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                      Your guide to software craftsmanship
                                      JUnit Recipes: Practical Methods for Programmer Testing
                                      2005 Gordon Pask Award for contribution Agile Software Practice
                                    • Steve Freeman
                                      ... Well, usually there isn t much to keep since I usually use a framework to do all the work. As a rule I keep the unit tests unless something significant
                                      Message 18 of 22 , Jan 2, 2008
                                      • 0 Attachment
                                        On 1 Jan 2008, at 22:08, Steve Howell wrote:
                                        > Ok, makes sense. In this case, do you tend to use the
                                        > mocks as scaffolding to be thrown away later, or do
                                        > you keep the mocks around even after you've gotten
                                        > around to implementing the "provider" layers (assuming
                                        > they're reasonably fast)?

                                        Well, usually there isn't much to "keep" since I usually use a
                                        framework to do all the work. As a rule I keep the unit tests unless
                                        something significant changes.

                                        S.

                                        Steve Freeman
                                        http://www.mockobjects.com

                                        Winner of the Agile Alliance Gordon Pask award 2006
                                      • J. B. Rainsberger
                                        ... Thanks for explaining. Don t mind me; I think it s great that so many people want to write about this, but it looks from a distance like a bunch of people
                                        Message 19 of 22 , Jan 2, 2008
                                        • 0 Attachment
                                          On Jan 2, 2008, at 12:59 , Vlad wrote:
                                          > My goal was to explain the differences in a way that I hoped would be
                                          > as intuitive as possible (i.e. informal and minus pompous language)
                                          > illustrated with several straightforward but practical examples. I
                                          > have also added the following links to other material on the subject.
                                          >
                                          > http://en.wikipedia.org/wiki/Mock_object
                                          > href="http://www.c2.com/cgi/wiki?MockObject
                                          > href="http://xunitpatterns.com/Test%20Double.html
                                          > href="http://martinfowler.com/articles/mocksArentStubs.html
                                          > href="http://langrsoft.com/articles/mocking.shtml
                                          >
                                          > My intent was also to offer my personal sense of when these different
                                          > kinds of test-only objects (aka test-doubles) should and should not be
                                          > used. If somebody offers corrections to my blog entry or additional
                                          > helpful links, I'll happily incorporate them.
                                          >
                                          > Based on what I was able to find with some searching online, I was
                                          > hoping to fill a small but helpful niche in the mock-objects/tdd
                                          > landscape.
                                          >
                                          Thanks for explaining. Don't mind me; I think it's great that so many
                                          people want to write about this, but it looks from a distance like a
                                          bunch of people writing the same thing about the same thing, and that
                                          usually makes me wonder why.

                                          This also prompts me to write "Stubs aren't mocks", which I've been
                                          meaning to do for a few months now. :)

                                          Take care.
                                          ----
                                          J. B. (Joe) Rainsberger :: http://www.jbrains.ca
                                          Your guide to software craftsmanship
                                          JUnit Recipes: Practical Methods for Programmer Testing
                                          2005 Gordon Pask Award for contribution Agile Software Practice
                                        • Adam Dymitruk
                                          ... You should keep your mocks. If you are using a powerful framework like Rhino Mocks, you can specify that what is important for you in that one test. The
                                          Message 20 of 22 , Jan 2, 2008
                                          • 0 Attachment
                                            > Ok, makes sense. In this case, do you tend to use the
                                            > mocks as scaffolding to be thrown away later, or do
                                            > you keep the mocks around even after you've gotten
                                            > around to implementing the "provider" layers (assuming
                                            > they're reasonably fast)?

                                            You should keep your mocks. If you are using a powerful framework like
                                            Rhino Mocks, you can specify that what is important for you in that
                                            one test. The rest is stubbed automatically for you.

                                            See the difference between CreateMock and DynamicMock in RhinoMocks.
                                            Stubs can be created with one line too. It's actually faster to stub
                                            with Rhino Mocks than without.

                                            Adam
                                          Your message has been successfully submitted and would be delivered to recipients shortly.