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

Agile requirements

Expand Messages
  • Jim Shore
    I ve just posted a new essay on my blog titled How I Use Fit. It s based on my recent post to this group about Fit and TDD. As I look back, I realize that
    Message 1 of 21 , Nov 30, 2005
    • 0 Attachment
      I've just posted a new essay on my blog titled "How I Use Fit." It's
      based on my recent post to this group about Fit and TDD.

      As I look back, I realize that I've now closed the circle on a pretty
      substantial cycle of essays on agile requirements. I now cover
      everything from planning months of releases down to how to write a
      single section of Fit document, the work of an hour. Pretty cool.
      (Hey, wait! Shouldn't I demand big bucks for this stuff?)

      * "Beyond Story Cards" describes how I prefer to handle requirements
      over the course of developing an entire software product.
      * "Fit Workflow" describes how I use Fit to facilitate collaboration on
      requirements during a single iteration.
      * "A Vision for Fit" gives a concrete example of using Fit to facilite
      collaboration.
      * Describe-Demonstrate-Develop, in "How I Use Fit" describes how I
      prefer to develop the Fit document, fixtures, and how actual software
      development comes into play.
      * "Elaborating on a Theme," also in "How I Use Fit," describes how I
      structure Fit documents and their examples.

      Find links to these essays at
      http://www.jamesshore.com/Blog/Agile-Requirements.html

      Cheers,
      Jim
      --
      James Shore -- Titanium IT -- Successful Software
      Recipient of 2005 Gordon Pask award for
      Contributions to Agile Practice

      phone: 503-267-5490
      email: jshore@...
      web/blog: http://www.jamesshore.com
    • Dan Bunea
      Hi Jim, Thank you for a very good reading. However I am a little bit confused about the balance between FIT automated customer tests and the normal
      Message 2 of 21 , Dec 1, 2005
      • 0 Attachment
        Hi Jim,

        Thank you for a very good reading.

        However I am a little bit confused about the balance between FIT automated
        customer tests and the normal unit/integration tests we write using TDD.

        I and a friend of mine, decided to write a new piece of software.It will
        be a desktop application written in .net, aimed to help small business
        better manage their activities (sales), especially in conditions where
        he's very mobile (pda/laptop/smartphone). He's more of a business expert
        of this domain (but still a programmer), and I come with my programming
        expertise.

        Now we are starting to gather the requirements. My usual way, the XP way
        is to plan the first relase first, by having a pile of user stories, then
        adding details to them as acceptance tests, more when the iteration is
        planned. However, writing FIT tests in fitnesse seems like a very nice
        thing to do, but what confuses us is what should be automated as
        unit/integration tests with NUnit/NMock and what should be automated as
        Fit tests?

        For instance, obviously an application like this will have an order form,
        order will have a list of order details. My way would be to build the
        form, using TDD and the MVP pattern. At the same time, I think that I
        could construct a test as a fit table, them make an adapter, and build the
        part of the form to make the test pass, build a new one and so on until I
        have m order form constructed. Fit tests are much more visual, but a lot
        slower. What should I do? What should really be Fit tests and what NUnit?
        Where's the line?

        Thanks,
        Dan




        On Thu, 01 Dec 2005 06:20:22 +0200, Jim Shore <jshore@...>
        wrote:

        > I've just posted a new essay on my blog titled "How I Use Fit." It's
        > based on my recent post to this group about Fit and TDD.
        >
        > As I look back, I realize that I've now closed the circle on a pretty
        > substantial cycle of essays on agile requirements. I now cover
        > everything from planning months of releases down to how to write a
        > single section of Fit document, the work of an hour. Pretty cool.
        > (Hey, wait! Shouldn't I demand big bucks for this stuff?)
        >
        > * "Beyond Story Cards" describes how I prefer to handle requirements
        > over the course of developing an entire software product.
        > * "Fit Workflow" describes how I use Fit to facilitate collaboration on
        > requirements during a single iteration.
        > * "A Vision for Fit" gives a concrete example of using Fit to facilite
        > collaboration.
        > * Describe-Demonstrate-Develop, in "How I Use Fit" describes how I
        > prefer to develop the Fit document, fixtures, and how actual software
        > development comes into play.
        > * "Elaborating on a Theme," also in "How I Use Fit," describes how I
        > structure Fit documents and their examples.
        >
        > Find links to these essays at
        > http://www.jamesshore.com/Blog/Agile-Requirements.html
        >
        > Cheers,
        > Jim



        --
        Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
      • Jim Shore
        Hi, Dan, ... I would suggest using NUnit to test everything that you as programmers feel should be tested. I don t see Fit as a testing tool. I use Fit to
        Message 3 of 21 , Dec 1, 2005
        • 0 Attachment
          Hi, Dan,

          Dan Bunea wrote:
          > However, writing FIT tests in fitnesse seems like a very nice
          > thing to do, but what confuses us is what should be automated as
          > unit/integration tests with NUnit/NMock and what should be automated as
          > Fit tests?

          I would suggest using NUnit to test everything that you as programmers
          feel should be tested. I don't see Fit as a testing tool.

          I use Fit to provide examples of complicated requirements. I don't try
          to test everything with Fit; I mainly just focus on examples of domain
          logic. I only occasionally provide examples of UI interaction or data
          translation: as a rule of thumb, I don't do it unless the UI interaction
          or data translation is complicated or Fit would facilitate discussion
          with non-programmers.

          I see NUnit and Fit as being orthogonal. They solve different problems
          and it's not that important that they both end up comparing 'expected'
          and 'actual' results.

          What's complicated about the application you're building? What's the
          "secret sauce"--the magic know-how that your application provides that
          no one else does? Provide Fit examples of that.

          I use TDD for everything, even if it has Fit examples too. When I write
          my NUnit tests, I use different data than my Fit examples. I TDD from a
          programming perspective... using data that reflects my knowledge of the
          program's edge cases, zero-one-many scenarios, etc.

          Cheers,
          Jim
          --
          James Shore -- Titanium IT -- Successful Software
          Recipient of 2005 Gordon Pask award for
          Contributions to Agile Practice

          phone: 503-267-5490
          email: jshore@...
          web/blog: http://www.jamesshore.com
        • Tim Haughton
          ... Not wanting to tell you your own mind, but I suspect that if you thought about it, you wouldn t see NUnit as a testing tool either. I d contend that Fit
          Message 4 of 21 , Dec 1, 2005
          • 0 Attachment
            On 02/12/05, Jim Shore <jshore@...> wrote:
            > I would suggest using NUnit to test everything that you as programmers
            > feel should be tested. I don't see Fit as a testing tool.
            >

            Not wanting to tell you your own mind, but I suspect that if you
            thought about it, you wouldn't see NUnit as a testing tool either. I'd
            contend that Fit serves two purposes, it is a specification tool and
            it's a facilitator of discussion between stakeholders, developers,
            testers etc. I'd also contend that xUnit is a specification tool, and
            a facilitator of discussion between developers. Of course, what xUnit
            specifies and what Fit specifies, are different.

            I also suspect that if I tell you any more about your own mind, you
            might become cross ;¬]

            >
            > I see NUnit and Fit as being orthogonal. They solve different problems
            > and it's not that important that they both end up comparing 'expected'
            > and 'actual' results.
            >

            I'm not sure I sense this orthogonality. Could you elaborate?

            Regards,

            Tim Haughton
          • Hugo Garcia
            ... Well, lets make that two crosses ;) I actually think it is possible to do story testing for developing the GUI. The trick is to just focus on the
            Message 5 of 21 , Dec 1, 2005
            • 0 Attachment
              On 02/12/05, Jim Shore <jshore@...> wrote:
              > I use Fit to provide examples of complicated requirements. I don't try
              > to test everything with Fit; I mainly just focus on examples of domain
              > logic. I only occasionally provide examples of UI interaction or data
              > translation: as a rule of thumb, I don't do it unless the UI interaction
              > or data translation is complicated or Fit would facilitate discussion
              > with non-programmers.

              On 12/2/05, Tim Haughton <timhaughton@...> wrote:
              > I also suspect that if I tell you any more about your own mind, you
              > might become cross ;¬]
              >

              Well, lets make that two crosses ;)

              I actually think it is possible to do story testing for developing the
              GUI. The trick is to just focus on the interaction of MVC and not on
              the widget or layout of the GUI. The latter is best left to the human
              eye or if you feel adventuresome then to a GUI scripting test tool.
              I will state the caveat start with your domain model but alwyas have
              in the back of your mind the GUI. Once your model is relatively well
              defined then you can move on to the GUI and further refine the model
              and view interaction.

              -H
            • Dadi Ingolfsson
              ... I must say I beg to differ here. Although I completely agree with your assessment that Fit and xUnit are specification tools, for different contexts, I do
              Message 6 of 21 , Dec 2, 2005
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, Tim Haughton
                <timhaughton@g...> wrote:
                >
                > On 02/12/05, Jim Shore <jshore@t...> wrote:
                > > I would suggest using NUnit to test everything that you as programmers
                > > feel should be tested. I don't see Fit as a testing tool.
                > >
                >
                > Not wanting to tell you your own mind, but I suspect that if you
                > thought about it, you wouldn't see NUnit as a testing tool either. I'd
                > contend that Fit serves two purposes, it is a specification tool and
                > it's a facilitator of discussion between stakeholders, developers,
                > testers etc. I'd also contend that xUnit is a specification tool, and
                > a facilitator of discussion between developers. Of course, what xUnit
                > specifies and what Fit specifies, are different.

                I must say I beg to differ here. Although I completely agree with your
                assessment that Fit and xUnit are specification tools, for different
                contexts, I do think that both of these tools are _also_ testing tools
                (feels like I´m stating the obvious, but hey!).

                I feel you guys may be going a bit too far with this "It´s a
                specification not a test" argument. I know that the specification
                quality of these tools may be primary, but let´s not talk about them
                like their other effects don´t exist.

                Best regards,
                Dadi.
              • Dan Bunea
                Hi Jim, Thank you very much for the response. Fit seems to have it s place where the scenarios get more complicated and NUnit reaches its limits. Like maybe
                Message 7 of 21 , Dec 2, 2005
                • 0 Attachment
                  Hi Jim,

                  Thank you very much for the response.

                  Fit seems to have it's place where the scenarios get more complicated and
                  NUnit reaches its limits. Like maybe shipping an order to a client, which
                  is done in one part of the application, then verifiing in the sales report
                  if the client has the balance properly modified.

                  From previous experience, my colleague said that a series of things, are
                  implemented diferently in for different clients: inventory management
                  (FIFO, LIFO, ..), validation rules (a client want to know the purchaser
                  agent, another doesn't care), product identification (for a client a
                  product means a 2 key pair: name and no: paper/1000 but for others, it
                  will be name, no and size: paper/1000/A4) and many others. Probably these
                  could be captured with the client as fit tables and then automated.

                  Thanks again for the answer,
                  Dan


                  On Thu, 01 Dec 2005 23:01:39 -0500, Jim Shore <jshore@...>
                  wrote:

                  > Hi, Dan,
                  >
                  > Dan Bunea wrote:
                  >> However, writing FIT tests in fitnesse seems like a very nice
                  >> thing to do, but what confuses us is what should be automated as
                  >> unit/integration tests with NUnit/NMock and what should be automated as
                  >> Fit tests?
                  >
                  > I would suggest using NUnit to test everything that you as programmers
                  > feel should be tested. I don't see Fit as a testing tool.
                  >
                  > I use Fit to provide examples of complicated requirements. I don't try
                  > to test everything with Fit; I mainly just focus on examples of domain
                  > logic. I only occasionally provide examples of UI interaction or data
                  > translation: as a rule of thumb, I don't do it unless the UI interaction
                  > or data translation is complicated or Fit would facilitate discussion
                  > with non-programmers.
                  >
                  > I see NUnit and Fit as being orthogonal. They solve different problems
                  > and it's not that important that they both end up comparing 'expected'
                  > and 'actual' results.
                  >
                  > What's complicated about the application you're building? What's the
                  > "secret sauce"--the magic know-how that your application provides that
                  > no one else does? Provide Fit examples of that.
                  >
                  > I use TDD for everything, even if it has Fit examples too. When I write
                  > my NUnit tests, I use different data than my Fit examples. I TDD from a
                  > programming perspective... using data that reflects my knowledge of the
                  > program's edge cases, zero-one-many scenarios, etc.
                  >
                  > Cheers,
                  > Jim



                  --
                  Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
                • Tim Haughton
                  ... I think that perhaps I should have said TDD is a specification process rather than xUnit is a specification tool. xUnit tools can of course be used for
                  Message 8 of 21 , Dec 2, 2005
                  • 0 Attachment
                    On 02/12/05, Dadi Ingolfsson <blubberplinth@...> wrote:
                    > I must say I beg to differ here. Although I completely agree with your
                    > assessment that Fit and xUnit are specification tools, for different
                    > contexts, I do think that both of these tools are _also_ testing tools
                    > (feels like I´m stating the obvious, but hey!).

                    I think that perhaps I should have said TDD is a specification process
                    rather than xUnit is a specification tool. xUnit tools can of course
                    be used for testing, but TDD uses them for specifying.

                    Cheers,

                    Tim
                  • Steven Gordon
                    ... And, as Dadi points out, xUnit supports the automated verification of TDD specifications, allowing them to also function as automated unit tests for any
                    Message 9 of 21 , Dec 2, 2005
                    • 0 Attachment
                      On 12/2/05, Tim Haughton <timhaughton@...> wrote:
                      >
                      > On 02/12/05, Dadi Ingolfsson <blubberplinth@...> wrote:
                      > > I must say I beg to differ here. Although I completely agree with your
                      > > assessment that Fit and xUnit are specification tools, for different
                      > > contexts, I do think that both of these tools are _also_ testing tools
                      > > (feels like I´m stating the obvious, but hey!).
                      >
                      > I think that perhaps I should have said TDD is a specification process
                      > rather than xUnit is a specification tool. xUnit tools can of course
                      > be used for testing, but TDD uses them for specifying.
                      >
                      > Cheers,
                      >
                      > Tim


                      And, as Dadi points out, xUnit supports the automated verification of TDD
                      specifications, allowing them to also function as automated unit tests for
                      any software that purports to satisfy those specifications.

                      Likewise, Fit/Fitnesse supports the automated verification of Application
                      Domain specifications, allowing them to also function as automated
                      integration tests for any software that purports to satisfy those
                      specifications.

                      Two sides of two similar coins.

                      Regards,

                      Steve


                      [Non-text portions of this message have been removed]
                    • Tim Haughton
                      ... Absolutely. Like I ve said elsewhere, TDD is about specifying, unit tests are about verifying. Cheers, Tim
                      Message 10 of 21 , Dec 2, 2005
                      • 0 Attachment
                        On 02/12/05, Steven Gordon <sgordonphd@...> wrote:
                        > And, as Dadi points out, xUnit supports the automated verification of TDD
                        > specifications, allowing them to also function as automated unit tests for
                        > any software that purports to satisfy those specifications.
                        >
                        > Likewise, Fit/Fitnesse supports the automated verification of Application
                        > Domain specifications, allowing them to also function as automated
                        > integration tests for any software that purports to satisfy those
                        > specifications.

                        Absolutely. Like I've said elsewhere, TDD is about specifying, unit
                        tests are about verifying.

                        Cheers,

                        Tim
                      • David Chelimsky
                        ... I ve generally operated this same way, but I ve been having some second thoughts. I was going to just respond here, but it got somewhat verbose so I posted
                        Message 11 of 21 , Dec 2, 2005
                        • 0 Attachment
                          Jim Shore wrote:
                          > I would suggest using NUnit to test everything that you as programmers
                          > feel should be tested. I don't see Fit as a testing tool.
                          >
                          > I use Fit to provide examples of complicated requirements. I don't try
                          > to test everything with Fit; I mainly just focus on examples of domain
                          > logic. I only occasionally provide examples of UI interaction or data
                          > translation: as a rule of thumb, I don't do it unless the UI interaction
                          > or data translation is complicated or Fit would facilitate discussion
                          > with non-programmers.
                          >
                          > I see NUnit and Fit as being orthogonal. They solve different problems
                          > and it's not that important that they both end up comparing 'expected'
                          > and 'actual' results.
                          >
                          > What's complicated about the application you're building? What's the
                          > "secret sauce"--the magic know-how that your application provides that
                          > no one else does? Provide Fit examples of that.
                          >
                          > I use TDD for everything, even if it has Fit examples too. When I write
                          > my NUnit tests, I use different data than my Fit examples. I TDD from a
                          > programming perspective... using data that reflects my knowledge of the
                          > program's edge cases, zero-one-many scenarios, etc.
                          >
                          > Cheers,
                          > Jim
                          >
                          I've generally operated this same way, but I've been having some second
                          thoughts. I was going to just respond here, but it got somewhat verbose
                          so I posted it:
                          http://butunclebob.com/ArticleS.DavidChelimsky.WhyLimitFit.
                          Coincidentally, that decision allowed me to better express some of the
                          things I had started to write in an email.

                          Looking forward to your (Jim's and everyone else's) comments either here
                          or on the blog.

                          Thanks,
                          David
                        • David Chelimsky
                          ... I ve generally operated this same way, but I ve been having some second thoughts. I was going to just respond here, but it got somewhat verbose so I posted
                          Message 12 of 21 , Dec 2, 2005
                          • 0 Attachment
                            Jim Shore wrote:
                            > I would suggest using NUnit to test everything that you as programmers
                            > feel should be tested. I don't see Fit as a testing tool.
                            >
                            > I use Fit to provide examples of complicated requirements. I don't
                            > try to test everything with Fit; I mainly just focus on examples of
                            > domain logic. I only occasionally provide examples of UI interaction
                            > or data translation: as a rule of thumb, I don't do it unless the UI
                            > interaction or data translation is complicated or Fit would
                            > facilitate discussion with non-programmers.
                            >
                            > I see NUnit and Fit as being orthogonal. They solve different
                            > problems and it's not that important that they both end up comparing
                            > 'expected' and 'actual' results.
                            >
                            > What's complicated about the application you're building? What's the
                            > "secret sauce"--the magic know-how that your application provides that
                            > no one else does? Provide Fit examples of that.
                            >
                            > I use TDD for everything, even if it has Fit examples too. When I
                            > write my NUnit tests, I use different data than my Fit examples. I
                            > TDD from a programming perspective... using data that reflects my
                            > knowledge of the program's edge cases, zero-one-many scenarios, etc.
                            >
                            > Cheers,
                            > Jim
                            >
                            I've generally operated this same way, but I've been having some second
                            thoughts. I was going to just respond here, but it got somewhat verbose
                            so I posted it:
                            http://butunclebob.com/ArticleS.DavidChelimsky.WhyLimitFit.
                            Coincidentally, that decision allowed me to better express some of the
                            things I had started to write in an email.

                            Looking forward to your (Jim's and everyone else's) comments either here
                            or on the blog.

                            Thanks,
                            David
                          • William Wake
                            On 12/2/05, David Chelimsky wrote: [In his blog entry] ... This is a place I see good leverage. I see the difference when a Fit test
                            Message 13 of 21 , Dec 2, 2005
                            • 0 Attachment
                              On 12/2/05, David Chelimsky <david@...> wrote:
                              [In his blog entry]
                              >"I've noticed that these tables lead me and my team to classes that operate
                              >directly on the basis of the described conditions." -

                              This is a place I see good leverage. I see the difference when a Fit
                              test is ready first and drives things - some object will directly
                              represent the decisions in the table. When the table is done
                              afterwards, there may or may not be such an object. (The correct
                              behavior may be there, but arises out of the interaction of objects.)

                              Having the "policy" object directly present in the system seems like a
                              big benefit to me - it gives you a traceability that the system
                              directly reflects the conditions.


                              Like everybody else, it seems, we're also trying to hit the right
                              balance between "tests as specification" versus "test as
                              verification", and of "customer-written" vs. "programmer-written". I
                              too find people easily fall into the "trap" of writing lots of
                              verification scripts rather than expressing clearly and directly what
                              they want to happen.

                              --
                              Bill Wake William.Wake@... www.xp123.com
                            • yahoogroups@jhrothjr.com
                              From: David Chelimsky To: extremeprogramming@yahoogroups.com
                              Message 14 of 21 , Dec 2, 2005
                              • 0 Attachment
                                From: "David Chelimsky"
                                <david.at.objectmentor.com@...>
                                To: "extremeprogramming@yahoogroups.com"
                                <extremeprogramming.at.yahoogroups.com@...>
                                Sent: Friday, December 02, 2005 8:38 AM
                                Subject: Re: [XP] Agile requirements


                                > Jim Shore wrote:
                                >> I would suggest using NUnit to test everything that you as programmers
                                >> feel should be tested. I don't see Fit as a testing tool.
                                >>
                                >> I use Fit to provide examples of complicated requirements. I don't
                                >> try to test everything with Fit; I mainly just focus on examples of
                                >> domain logic. I only occasionally provide examples of UI interaction
                                >> or data translation: as a rule of thumb, I don't do it unless the UI
                                >> interaction or data translation is complicated or Fit would
                                >> facilitate discussion with non-programmers.
                                >>
                                >> I see NUnit and Fit as being orthogonal. They solve different
                                >> problems and it's not that important that they both end up comparing
                                >> 'expected' and 'actual' results.
                                >>
                                >> What's complicated about the application you're building? What's the
                                >> "secret sauce"--the magic know-how that your application provides that
                                >> no one else does? Provide Fit examples of that.
                                >>
                                >> I use TDD for everything, even if it has Fit examples too. When I
                                >> write my NUnit tests, I use different data than my Fit examples. I
                                >> TDD from a programming perspective... using data that reflects my
                                >> knowledge of the program's edge cases, zero-one-many scenarios, etc.
                                >>
                                >> Cheers,
                                >> Jim
                                >>
                                > I've generally operated this same way, but I've been having some second
                                > thoughts. I was going to just respond here, but it got somewhat verbose
                                > so I posted it:
                                > http://butunclebob.com/ArticleS.DavidChelimsky.WhyLimitFit.
                                > Coincidentally, that decision allowed me to better express some of the
                                > things I had started to write in an email.
                                >
                                > Looking forward to your (Jim's and everyone else's) comments either here
                                > or on the blog.

                                I think there's an element here that really does need expressing: _choice_.

                                I'd like to keep a separation between the external specification, which
                                ultimately comes from the customers and which needs to be expressed
                                in the terms natural to the business we're supporting, and the internal
                                specification, which, while necessarilly related to the external
                                specification,
                                may be related in ways which may not be directly expressable.

                                However, "may" does not equal "must". I've also noted that there are
                                a class of tables which seem to map, very plainly and simply, to
                                objects (or something) in the software, and where separate tests are
                                not only redundant, they are a violation of the DRY principle: Don't
                                repeat yourself.

                                The biggest example I've got here (within FIT) is the mapping from
                                labels to programming language identifiers. The unittest (unittest is
                                Python's version of xUnit) code for this duplicates the table in
                                Rick Mugridge's specification suite for ExtendedCamelCase.
                                I've got other examples, and I've noticed the tendency to write
                                some HTML, especially to drive fixtures from the doTable,
                                doRows or doRow methods.

                                I don't think there's a real way around this since so much of
                                FIT revolves around the parse tree. I don't think I'd do this
                                in most real world applications, since the closest they get
                                to HTML is the FIT fixtures. The problem just doesn't occur
                                unless you're either working on FIT or on an HTML part of
                                a web application.

                                Much of the rest is simply tool support. Living in a tool
                                impoverished world gives me a somewhat different perspective.
                                I don't, for example, have anything that lets me click on a line
                                in a stack trace and go directly to the line in the code. I run
                                all my tests from a script in a command window. This may be
                                dark ages, but it does give me more leverage in running tests.
                                If I want to run FIT in my "t all" script, then it's very simple:
                                just add the necessary commands to the script. All I need
                                then is a way to specify which tests are wired directly to
                                functionality, and I'm almost home.

                                As it turns out, it's relatively easy in FitNesse to say
                                which tests to run: that's the virtual suite functionality.
                                I've got the same functionality (plus more) in batch that
                                will be in my 0.8 release. What's now missing is a way
                                of looking at the output and pinpointing anything that
                                went wrong (that is, stack traces).

                                In counterpoint though, I think Jim's viewpoint has one
                                really major plus: keeping things separate reduces coupling,
                                and coupling impacts our ability to change. Do I really want
                                the customer changing tables that I'm using as part of my
                                program specification suite? Especially if the change impacts
                                the design in a way that I can no longer use the table directly
                                as a developer specification?

                                John Roth


                                > Thanks,
                                > David
                                >
                                >
                                >
                                >
                                > To Post a message, send it to: extremeprogramming@...
                                >
                                > To Unsubscribe, send a blank message to:
                                > extremeprogramming-unsubscribe@...
                                >
                                > ad-free courtesy of objectmentor.com
                                > Yahoo! Groups Links
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                                >
                              • David Chelimsky
                                ... John - I appreciate the notion of keeping things separate. I don t want the customer changing tables that *I m* using as *programmer tests*. So that s a
                                Message 15 of 21 , Dec 2, 2005
                                • 0 Attachment
                                  yahoogroups@... wrote:
                                  > In counterpoint though, I think Jim's viewpoint has one
                                  > really major plus: keeping things separate reduces coupling,
                                  > and coupling impacts our ability to change. Do I really want
                                  > the customer changing tables that I'm using as part of my
                                  > program specification suite? Especially if the change impacts
                                  > the design in a way that I can no longer use the table directly
                                  > as a developer specification?
                                  John - I appreciate the notion of keeping things separate. I don't want
                                  the customer changing tables that *I'm* using as *programmer tests*. So
                                  that's a problem if we're trying to reduce duplication - especially with
                                  the current lack of good FIT refatoring tools. I'd probably end up w/
                                  duplication between the customer's fit tests and mine :)

                                  However, I do get a little jealous of my customers who get to express
                                  their specs in this beautiful, simple, easy to glean tabular format when
                                  I feel sort of stuck w/ a less expressive tool (for certain problems) in
                                  xUnit. Obviously xUnit is extraordinarily expressive, and I have no
                                  interest in replacing xUnit w/ FIT as a unit testing tool. But I do want
                                  to be able to take advantage of FIT where it makes sense to do so.

                                  -David Chelimsky
                                • Rob Park
                                  My 2 cents (or at least how we treat it) are that the details of your MVP, subsequent DAOs, and any of the other little individual things it must do are
                                  Message 16 of 21 , Dec 2, 2005
                                  • 0 Attachment
                                    My 2 cents (or at least how we treat it) are that the details of your MVP,
                                    subsequent DAOs, and any of the other little individual things it must do
                                    are subjects for unit testing (aka programmer tests). Fit fixtures can be
                                    written to tap into your presenter (as just another view). Then you can
                                    right FitNesse tests (aka customer tests) to simulate and test important
                                    customer actions, which inevitably are very closely aligned with the story
                                    (more than the code itself).

                                    Hope that helps.

                                    .rob.

                                    >...
                                    >
                                    >Now we are starting to gather the requirements. My usual way, the XP way
                                    >is to plan the first relase first, by having a pile of user stories, then
                                    >adding details to them as acceptance tests, more when the iteration is
                                    >planned. However, writing FIT tests in fitnesse seems like a very nice
                                    >thing to do, but what confuses us is what should be automated as
                                    >unit/integration tests with NUnit/NMock and what should be automated as
                                    >Fit tests?
                                    >
                                    >For instance, obviously an application like this will have an order form,
                                    >order will have a list of order details. My way would be to build the
                                    >form, using TDD and the MVP pattern. At the same time, I think that I
                                    >could construct a test as a fit table, them make an adapter, and build the
                                    >part of the form to make the test pass, build a new one and so on until I
                                    >have m order form constructed. Fit tests are much more visual, but a lot
                                    >slower. What should I do? What should really be Fit tests and what NUnit?
                                    >Where's the line?
                                    >
                                    >Thanks,
                                    >Dan
                                    >
                                    >
                                    >
                                    >
                                    >On Thu, 01 Dec 2005 06:20:22 +0200, Jim Shore <jshore@...>
                                    >wrote:
                                    >
                                    > > I've just posted a new essay on my blog titled "How I Use Fit." It's
                                    > > based on my recent post to this group about Fit and TDD.
                                    > >
                                    > > As I look back, I realize that I've now closed the circle on a pretty
                                    > > substantial cycle of essays on agile requirements. I now cover
                                    > > everything from planning months of releases down to how to write a
                                    > > single section of Fit document, the work of an hour. Pretty cool.
                                    > > (Hey, wait! Shouldn't I demand big bucks for this stuff?)
                                    > >
                                    > > * "Beyond Story Cards" describes how I prefer to handle requirements
                                    > > over the course of developing an entire software product.
                                    > > * "Fit Workflow" describes how I use Fit to facilitate collaboration on
                                    > > requirements during a single iteration.
                                    > > * "A Vision for Fit" gives a concrete example of using Fit to facilite
                                    > > collaboration.
                                    > > * Describe-Demonstrate-Develop, in "How I Use Fit" describes how I
                                    > > prefer to develop the Fit document, fixtures, and how actual software
                                    > > development comes into play.
                                    > > * "Elaborating on a Theme," also in "How I Use Fit," describes how I
                                    > > structure Fit documents and their examples.
                                    > >
                                    > > Find links to these essays at
                                    > > http://www.jamesshore.com/Blog/Agile-Requirements.html
                                    > >
                                    > > Cheers,
                                    > > Jim
                                    >
                                    >
                                    >
                                    >--
                                    >Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
                                    >
                                    >
                                    >To Post a message, send it to: extremeprogramming@...
                                    >
                                    >To Unsubscribe, send a blank message to:
                                    >extremeprogramming-unsubscribe@...
                                    >
                                    >ad-free courtesy of objectmentor.com
                                    >Yahoo! Groups Links
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                    >
                                  • Rick Mugridge
                                    ... Hi David, I have no problem, in principle, in using Fit for unit tests and JUnit for storytests. It depends on the abilities of the human readers and the
                                    Message 17 of 21 , Dec 2, 2005
                                    • 0 Attachment
                                      David Chelimsky wrote:

                                      > ...
                                      >
                                      >However, I do get a little jealous of my customers who get to express
                                      >their specs in this beautiful, simple, easy to glean tabular format when
                                      >I feel sort of stuck w/ a less expressive tool (for certain problems) in
                                      >xUnit. Obviously xUnit is extraordinarily expressive, and I have no
                                      >interest in replacing xUnit w/ FIT as a unit testing tool. But I do want
                                      >to be able to take advantage of FIT where it makes sense to do so.
                                      >
                                      >-David Chelimsky
                                      >
                                      >
                                      Hi David,

                                      I have no problem, in principle, in using Fit for unit tests and JUnit
                                      for storytests. It depends on the abilities of the human readers and the
                                      writers, and then on the form of the tests as to which is best. (I also
                                      use Fit for defining builds and other things besides.)

                                      I do agree that the Customers' storytests need to be kept separate from
                                      the programmers' Fit unit tests. I also want to keep separate the Fit
                                      storytests that define the PUBLISHED LANGUAGE (DomainDrivenDesign) for a
                                      subsystem. And also the storytests that are specific to installation and
                                      on-site maintenance. And etc.

                                      Cheers, Rick
                                    • Rick Mugridge
                                      Yes, I think they re just tackling different levels of the system. With good tool support, I could image using Fit for all my unit testing as well. I look
                                      Message 18 of 21 , Dec 2, 2005
                                      • 0 Attachment
                                        Yes, I think they're just tackling different levels of the system. With
                                        good tool support, I could image using Fit for all my unit testing as
                                        well. I look forward to trying this out.

                                        Cheers, Rick

                                        Steven Gordon wrote:

                                        > ...
                                        >
                                        >And, as Dadi points out, xUnit supports the automated verification of TDD
                                        >specifications, allowing them to also function as automated unit tests for
                                        >any software that purports to satisfy those specifications.
                                        >
                                        >Likewise, Fit/Fitnesse supports the automated verification of Application
                                        >Domain specifications, allowing them to also function as automated
                                        >integration tests for any software that purports to satisfy those
                                        >specifications.
                                        >
                                        >Two sides of two similar coins.
                                        >
                                        >Regards,
                                        >
                                        >Steve
                                        >
                                        >
                                        >


                                        [Non-text portions of this message have been removed]
                                      • Rick Mugridge
                                        Hi David, Yes, I agree with your point of view and have seen it work very well in practice. With calculation rules like your validation table, it makes much
                                        Message 19 of 21 , Dec 2, 2005
                                        • 0 Attachment
                                          Hi David,

                                          Yes, I agree with your point of view and have seen it work very well in
                                          practice. With calculation rules like your validation table, it makes
                                          much sense to have them expressed directly in the code, taking a domain
                                          driven design approach. I've noticed that tthe business logic often gets
                                          little attention, and this helps bring a focus to it.

                                          Of course, there still needs to be unit tests for driving the
                                          infrastructure (non domain) parts.

                                          Cheers, Rick

                                          David Chelimsky wrote:

                                          >Jim Shore wrote:
                                          >
                                          >
                                          >>I would suggest using NUnit to test everything that you as programmers
                                          >>feel should be tested. I don't see Fit as a testing tool.
                                          >>
                                          >>I use Fit to provide examples of complicated requirements. I don't try
                                          >>to test everything with Fit; I mainly just focus on examples of domain
                                          >>logic. I only occasionally provide examples of UI interaction or data
                                          >>translation: as a rule of thumb, I don't do it unless the UI interaction
                                          >> or data translation is complicated or Fit would facilitate discussion
                                          >>with non-programmers.
                                          >>
                                          >>I see NUnit and Fit as being orthogonal. They solve different problems
                                          >>and it's not that important that they both end up comparing 'expected'
                                          >>and 'actual' results.
                                          >>
                                          >>What's complicated about the application you're building? What's the
                                          >>"secret sauce"--the magic know-how that your application provides that
                                          >>no one else does? Provide Fit examples of that.
                                          >>
                                          >>I use TDD for everything, even if it has Fit examples too. When I write
                                          >>my NUnit tests, I use different data than my Fit examples. I TDD from a
                                          >>programming perspective... using data that reflects my knowledge of the
                                          >>program's edge cases, zero-one-many scenarios, etc.
                                          >>
                                          >>Cheers,
                                          >>Jim
                                          >>
                                          >>
                                          >>
                                          >I've generally operated this same way, but I've been having some second
                                          >thoughts. I was going to just respond here, but it got somewhat verbose
                                          >so I posted it:
                                          >http://butunclebob.com/ArticleS.DavidChelimsky.WhyLimitFit.
                                          >Coincidentally, that decision allowed me to better express some of the
                                          >things I had started to write in an email.
                                          >
                                          >Looking forward to your (Jim's and everyone else's) comments either here
                                          >or on the blog.
                                          >
                                          >Thanks,
                                          >David
                                          >
                                          >
                                          >
                                          >To Post a message, send it to: extremeprogramming@...
                                          >
                                          >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                                          >
                                          >ad-free courtesy of objectmentor.com
                                          >Yahoo! Groups Links
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >
                                          >


                                          [Non-text portions of this message have been removed]
                                        • Dominic Williams
                                          ... Surely, evolving an expressive and consise domain-specific language for the programmer tests is exactly the same exercise as what XP tells us to do with
                                          Message 20 of 21 , Dec 6, 2005
                                          • 0 Attachment
                                            David Chelimsky started:

                                            > However, I do get a little jealous of my customers
                                            > who get to express their specs in this beautiful,
                                            > simple, easy to glean tabular format when I feel sort
                                            > of stuck w/ a less expressive tool (for certain
                                            > problems) in xUnit.

                                            and Rick Mugridge continued:

                                            > With good tool support, I could image using Fit for
                                            > all my unit testing as well. I look forward to trying
                                            > this out.

                                            Surely, evolving an expressive and consise
                                            domain-specific language for the programmer tests is
                                            exactly the same exercise as what XP tells us to do
                                            with the code?

                                            I am wondering what it says about our programming
                                            languages or our ability to use them creatively that
                                            programmers should be wanting to use FIT rather than
                                            code for programmer tests...

                                            Would you still want to if you were coding in Lisp or
                                            Smalltalk or Ruby or something?

                                            Anyway, even with C++ or Java, I don't think I'd want
                                            to do programmer tests in FIT: when coding tests is
                                            painful, I know I need to improve the design.

                                            Regards,

                                            Dominic Williams
                                            http://www.dominicwilliams.net

                                            ----
                                          • Rick Mugridge
                                            ... Please notice that I m not advocating this as a general approach! And I doubt that I ll end up wanting to change. But I think it s worth trying it. TDD
                                            Message 21 of 21 , Dec 6, 2005
                                            • 0 Attachment
                                              Dominic Williams wrote:

                                              >David Chelimsky started:
                                              >
                                              >
                                              >
                                              >>However, I do get a little jealous of my customers
                                              >>who get to express their specs in this beautiful,
                                              >>simple, easy to glean tabular format when I feel sort
                                              >>of stuck w/ a less expressive tool (for certain
                                              >>problems) in xUnit.
                                              >>
                                              >>
                                              >
                                              >and Rick Mugridge continued:
                                              >
                                              >
                                              >
                                              >>With good tool support, I could image using Fit for
                                              >>all my unit testing as well. I look forward to trying
                                              >>this out.
                                              >>
                                              >>
                                              >
                                              >Surely, evolving an expressive and consise
                                              >domain-specific language for the programmer tests is
                                              >exactly the same exercise as what XP tells us to do
                                              >with the code?
                                              >
                                              >I am wondering what it says about our programming
                                              >languages or our ability to use them creatively that
                                              >programmers should be wanting to use FIT rather than
                                              >code for programmer tests...
                                              >
                                              >
                                              Please notice that I'm not advocating this as a general approach! And I
                                              doubt that I'll end up wanting to change. But I think it's worth trying
                                              it. TDD would be unknown if someone didn't try something that seemed
                                              very odd to begin with. I often learn something from pushing the
                                              boundaries, even if I just understand my assumptions better.

                                              >Would you still want to if you were coding in Lisp or
                                              >Smalltalk or Ruby or something?
                                              >Anyway, even with C++ or Java, I don't think I'd want
                                              >to do programmer tests in FIT: when coding tests is
                                              >painful, I know I need to improve the design.
                                              >
                                              >
                                              Fit could be useful is in setting up compex object structures, which can
                                              be a real pain in Java. Ruby, of course, provides much better support
                                              for this. But I personally prefer statically typed languages as a design
                                              medium, having seriously tried a variety of types of language.

                                              So, yes, it highlights the limits of the design of programming
                                              languages, which are still (mostly) in the days of ascii.

                                              Cheers, Rick

                                              >Regards,
                                              >
                                              >Dominic Williams
                                              >http://www.dominicwilliams.net
                                              >
                                              >


                                              [Non-text portions of this message have been removed]
                                            Your message has been successfully submitted and would be delivered to recipients shortly.