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

Stubs, Fakes, and Mocks

Expand Messages
  • Vlad
    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
    Message 1 of 22 , Dec 30, 2007
      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
    • Steve Howell
      ... http://vladimirlevin.blogspot.com/2007/11/stubs-fakes-mocks.html ... Nice blog entry--I think it s a good overview. I like the examples--real time sensors,
      Message 2 of 22 , Dec 30, 2007
        --- Vlad <vladimir_levin@...> 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
        >

        Nice blog entry--I think it's a good overview.

        I like the examples--real time sensors, memory-only
        implementations, and hand-rolled mock.

        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.








        ____________________________________________________________________________________
        Be a better friend, newshound, and
        know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
      • 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 3 of 22 , Dec 30, 2007
          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 4 of 22 , Dec 30, 2007
            --- 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 5 of 22 , Dec 31, 2007
              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 6 of 22 , Dec 31, 2007
                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 7 of 22 , Dec 31, 2007
                  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 8 of 22 , Dec 31, 2007
                    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 9 of 22 , Dec 31, 2007
                      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 10 of 22 , Dec 31, 2007
                        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 11 of 22 , Jan 1, 2008
                          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 12 of 22 , Jan 1, 2008
                            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 13 of 22 , Jan 1, 2008
                              --- 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 14 of 22 , Jan 1, 2008
                                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 15 of 22 , Jan 1, 2008
                                  --- "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 16 of 22 , Jan 2, 2008
                                    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 17 of 22 , Jan 2, 2008
                                      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 18 of 22 , Jan 2, 2008
                                        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 19 of 22 , Jan 2, 2008
                                          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 20 of 22 , Jan 2, 2008
                                            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 21 of 22 , Jan 2, 2008
                                              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 22 of 22 , Jan 2, 2008
                                                > 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.