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

RE: [TDD] One Expectation Per Example

Expand Messages
  • Donaldson, John (GEO)
    JMB, thanks a good clear article. Just one point of information: the simple NMock which is part of Nunit has a Strict attribute on its mocks, and if you have
    Message 1 of 7 , May 11, 2007
      JMB,

      thanks a good clear article. Just one point of information: the simple
      NMock
      which is part of Nunit has a "Strict" attribute on its mocks, and if you
      have
      strict=false then you don't get errors from methods called on the mock,
      for
      which you haven't set expectations.

      John D.

      > -----Original Message-----
      > From: testdrivendevelopment@yahoogroups.com
      > [mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of
      > jupitermoon_beam
      > Sent: Thursday, May 10, 2007 5:54 PM
      > To: testdrivendevelopment@yahoogroups.com
      > Subject: [TDD] One Expectation Per Example
      >
      > A while ago Dave Astels published an article called One
      > Expectation Per Example which was very interesting.
      >
      > Unfortunately he wrote it in Ruby and used RSpec which made
      > it both difficult to read for non-Ruby developers and RSpec
      > (as well as using a different syntax) has some features which
      > the likes of xMock (and NSpec for that matter) don't have.
      >
      > So I took the liberty of translating it into C# so if anyone
      > is interested in taking another look:
      > http://jupitermoonbeam.blogspot.com/2007/05/dont-expect-too-much.html
      >
      > Any comments (technical or editorial) would be more than
      > welcome and I hope some people find it useful.
      >
    • jupitermoon_beam
      Thanks for the feedback John, I ve updated my article to reference your post.
      Message 2 of 7 , May 16, 2007
        Thanks for the feedback John, I've updated my article to reference
        your post.

        --- In testdrivendevelopment@yahoogroups.com, "Donaldson, John
        \(GEO\)" <john.m.donaldson@...> wrote:
        >
        > JMB,
        >
        > thanks a good clear article. Just one point of information: the simple
        > NMock
        > which is part of Nunit has a "Strict" attribute on its mocks, and if you
        > have
        > strict=false then you don't get errors from methods called on the mock,
        > for
        > which you haven't set expectations.
        >
        > John D.
        >
        > > -----Original Message-----
        > > From: testdrivendevelopment@yahoogroups.com
        > > [mailto:testdrivendevelopment@yahoogroups.com] On Behalf Of
        > > jupitermoon_beam
        > > Sent: Thursday, May 10, 2007 5:54 PM
        > > To: testdrivendevelopment@yahoogroups.com
        > > Subject: [TDD] One Expectation Per Example
        > >
        > > A while ago Dave Astels published an article called One
        > > Expectation Per Example which was very interesting.
        > >
        > > Unfortunately he wrote it in Ruby and used RSpec which made
        > > it both difficult to read for non-Ruby developers and RSpec
        > > (as well as using a different syntax) has some features which
        > > the likes of xMock (and NSpec for that matter) don't have.
        > >
        > > So I took the liberty of translating it into C# so if anyone
        > > is interested in taking another look:
        > > http://jupitermoonbeam.blogspot.com/2007/05/dont-expect-too-much.html
        > >
        > > Any comments (technical or editorial) would be more than
        > > welcome and I hope some people find it useful.
        > >
        >
      • Mirkana Aleh
        See Each Test Should Test Only ONE scenario [Non-text portions of this message
        Message 3 of 7 , May 16, 2007
          See Each Test Should Test Only ONE scenario
          <http://www.elilopian.com/2006/10/31/multiple-asserts-in-a-single-unit-t\
          est/>


          [Non-text portions of this message have been removed]
        • jupitermoon_beam
          Hi Mirkana, I think some of the techniques outlined by Dave are also valid on a scenario basis as well. Of course it s individual choice about whether you feel
          Message 4 of 7 , May 17, 2007
            Hi Mirkana,

            I think some of the techniques outlined by Dave are also valid on a
            scenario basis as well.

            Of course it's individual choice about whether you feel Assert/Expect
            Once vs per scenario and I think it can become a bit protestant vs
            catholics.

            Though I would say that a scenario is a grey area: it can encompass as
            little or as much as you like. Sometimes there are aspects of the
            behaviour of a class that we are MORE interested in one scenario than
            another. For example ShouldThrowErrorWhen may only be interested in
            ensuring that a bad result returned from a particular object throws
            the exception. In those scenarios we just want the mocks not relevant
            to the scenario to react quitely rather than have to programme their
            every move.

            --- In testdrivendevelopment@yahoogroups.com, "Mirkana Aleh"
            <elilopian@...> wrote:
            >
            > See Each Test Should Test Only ONE scenario
            >
            <http://www.elilopian.com/2006/10/31/multiple-asserts-in-a-single-unit-t\
            > est/>
            >
            >
            > [Non-text portions of this message have been removed]
            >
          • Tim Haughton
            ... Hi, the one-assert-per-test rule is better explained by the notion of the stable state pattern . In other words, individual tests do no setup work, they
            Message 5 of 7 , May 17, 2007
              On 10/05/07, jupitermoon_beam <jupitermoonbeam@...> wrote:
              > A while ago Dave Astels published an article called One Expectation
              > Per Example which was very interesting.

              Hi, the "one-assert-per-test" rule is better explained by the notion
              of the "stable state pattern". In other words, individual tests do no
              setup work, they simply assert. When you follow this, you have very
              clear, very granular tests. This will very often, but not always lead
              to one-assert-per-test.

              --
              Regards,

              Tim Haughton
            • jupitermoon_beam
              ... I d agree with that. ... I did try and achieve this in the article when I refactored the tests to do the stubbing and the call in the TearDown: that way
              Message 6 of 7 , May 18, 2007
                > Hi, the "one-assert-per-test" rule is better explained by the notion
                > of the "stable state pattern".
                I'd agree with that.

                > In other words, individual tests do no
                > setup work, they simply assert. When you follow this, you have very
                > clear, very granular tests. This will very often, but not always lead
                > to one-assert-per-test.

                I did try and achieve this in the article when I refactored the tests
                to do the stubbing and the call in the TearDown: that way the
                individual test only did the Expect and not all the Stubbing etc. As
                I argued in my article this feels strange but unless you use a mock
                library which just quitely ignores the unexpected calls I can't think
                of a better way of doing it.

                Overall for those who like a one-assert style it's quite a challange
                to try and adapt that thinking to mocks and I think Dave's article
                (and hopefully my translation) really throws some light in that direction.

                --- In testdrivendevelopment@yahoogroups.com, "Tim Haughton"
                <timhaughton@...> wrote:
                >
                > On 10/05/07, jupitermoon_beam <jupitermoonbeam@...> wrote:
                > > A while ago Dave Astels published an article called One Expectation
                > > Per Example which was very interesting.
                >
                > Hi, the "one-assert-per-test" rule is better explained by the notion
                > of the "stable state pattern". In other words, individual tests do no
                > setup work, they simply assert. When you follow this, you have very
                > clear, very granular tests. This will very often, but not always lead
                > to one-assert-per-test.
                >
                > --
                > Regards,
                >
                > Tim Haughton
                >
              Your message has been successfully submitted and would be delivered to recipients shortly.