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

Fit and Unit Tests, how to go about it

Expand Messages
  • Heinrich Breedt
    Hi, I have been using Nunit now for quite a while and i love TDD. I am now starting to use Fit, and now kinda wondering what my rhytm of programming should
    Message 1 of 18 , Nov 25, 2005
    • 0 Attachment
      Hi,

      I have been using Nunit now for quite a while and i love TDD.
      I am now starting to use Fit, and now kinda wondering what my rhytm of
      programming should look like.

      Do I start with the User acceptance tests, make them work in the "glue"
      classes, and then start the unit tests?

      Seems logical, but i find that in order to make the Fit tests pass, i
      write quite a bit of code that is not under test, which i then put
      under test "after the fact". Makes me uncomfortable.

      Do i just leave the Fit Tests not working (not compiling) while a TDD
      the domain classes?

      Any thoughts?
    • Ron Jeffries
      ... Back in the olden days, the acceptance tests were the last thing to run, as the code built up to have the power to make them work. Ron Jeffries
      Message 2 of 18 , Nov 25, 2005
      • 0 Attachment
        On Friday, November 25, 2005, at 8:45:18 AM, Heinrich Breedt wrote:

        > Do i just leave the Fit Tests not working (not compiling) while a TDD
        > the domain classes?

        Back in the olden days, the acceptance tests were the last thing to
        run, as the code built up to have the power to make them work.

        Ron Jeffries
        www.XProgramming.com
        The main reason that testing at the end of a development cycle finds
        problems is not that problems were put in near the end, it is that
        testing was put off until then.
      • Dale Emery
        Hi Heinrich, ... I ve just started with FitNesse myself, as part of XP-for-one. I m sorting out the same question. I noticed yesterday that my second batch of
        Message 3 of 18 , Nov 25, 2005
        • 0 Attachment
          Hi Heinrich,

          > I have been using Nunit now for quite a while and i love TDD.
          > I am now starting to use Fit, and now kinda wondering what my
          > rhytm of programming should look like.

          I've just started with FitNesse myself, as part of XP-for-one.
          I'm sorting out the same question.

          I noticed yesterday that my second batch of tests look too much
          like unit tests--they aren't tied to a particular user story.

          So I'm changing my rhythm, so that before I write an acceptance
          test I first record the story that it tests. I think I'll use
          FitNesse's wiki for that.

          > Do I start with the User acceptance tests, make them work in
          > the "glue" classes, and then start the unit tests?
          >
          > Seems logical, but i find that in order to make the Fit tests
          > pass, i write quite a bit of code that is not under test,
          > which i then put under test "after the fact". Makes me
          > uncomfortable.
          >
          > Do i just leave the Fit Tests not working (not compiling)
          > while a TDD the domain classes?

          I've been using a small story-test-driven-development cycle:
          Write an acceptance test, write the code that passes it,
          refactor. This isn't working for me. I've quickly learned that
          it encourages me to think about classes too early. While I'm
          writing acceptance tests, I want to focus on the story, and not
          on classes.

          So I'm shifting my approach toward what I understand is the usual
          STDD cycle: Write some acceptance tests for a story, then use
          TDD to implement the story to pass one acceptance test at a time.

          I'm wondering about the advantages and disadvantages of using
          Fit/FitNesse for unit tests. Has anybody tried this? How did it go?

          Dale

          --
          Dale Emery, Consultant
          Inspiring Leadership for Software People
          Web: http://www.dhemery.com
          Weblog: http://www.dhemery.com/cwd
        • Stephen Freeman
          ... you might find that you need more fixture code to keep the tests readable as a domain language. We ve been using FIT for nearly a year and, first, you have
          Message 4 of 18 , Nov 26, 2005
          • 0 Attachment
            On 25 Nov 2005, at 21:07, Dale Emery wrote:
            > I've been using a small story-test-driven-development cycle:
            > Write an acceptance test, write the code that passes it,
            > refactor. This isn't working for me. I've quickly learned that
            > it encourages me to think about classes too early. While I'm
            > writing acceptance tests, I want to focus on the story, and not
            > on classes.

            you might find that you need more fixture code to keep the tests
            readable as a domain language. We've been using FIT for nearly a year
            and, first, you have to let the tests develop over time as you get
            used to them and, second, we have a lot of fixture code to get away
            from any hit of their implementation. Using FitLibrary helps too.

            S.
          • Sam Gentile
            Don t have much time now but I m going to ask Jim Shore to comment here as he has been teachig our team story-driven development using FIT and has a lot of
            Message 5 of 18 , Nov 26, 2005
            • 0 Attachment
              Don't have much time now but I'm going to ask Jim Shore to comment here as
              he has been teachig our team story-driven development using FIT and has a
              lot of great perspective on it.More soon-)

              On 11/26/05, Stephen Freeman <smgfreeman@...> wrote:
              >
              > On 25 Nov 2005, at 21:07, Dale Emery wrote:
              > > I've been using a small story-test-driven-development cycle:
              > > Write an acceptance test, write the code that passes it,
              > > refactor. This isn't working for me. I've quickly learned that
              > > it encourages me to think about classes too early. While I'm
              > > writing acceptance tests, I want to focus on the story, and not
              > > on classes.
              >
              > you might find that you need more fixture code to keep the tests
              > readable as a domain language. We've been using FIT for nearly a year
              > and, first, you have to let the tests develop over time as you get
              > used to them and, second, we have a lot of fixture code to get away
              > from any hit of their implementation. Using FitLibrary helps too.
              >
              > S.
              >
              >
              >
              > 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
              >
              >
              >
              >
              >
              >
              >


              --
              Sam Gentile
              INETA Speaker, Microsoft MVP-Solutions Architect, UG Leader Beantown .NET
              .NET Blog: http://samgentile.com/blog/
              .NET Portal: http://samgentile.com/


              [Non-text portions of this message have been removed]
            • Rick Mugridge
              ... I do this for my development of FitLibrary, and have used it on several other projects, and find it very effective. In general, I find value in thinking
              Message 6 of 18 , Nov 28, 2005
              • 0 Attachment
                Stephen Freeman wrote:

                >On 25 Nov 2005, at 21:07, Dale Emery wrote:
                >
                >
                >>I've been using a small story-test-driven-development cycle:
                >>Write an acceptance test, write the code that passes it,
                >>refactor. This isn't working for me. I've quickly learned that
                >>it encourages me to think about classes too early. While I'm
                >>writing acceptance tests, I want to focus on the story, and not
                >>on classes.
                >>
                >>
                I do this for my development of FitLibrary, and have used it on several
                other projects, and find it very effective. In general, I find value in
                thinking about the domain objects that emerge from writing the
                storytests. They help to structure the storytests. As the code is
                written, issues arise about the domain that may lead to insights in the
                domain model, leading to changes in the storytests and then in the code.
                The storytests evolve over time, as the domain understanding evolves and
                the system is developed. So minimising redundancy in the storytests is
                important (eg, extract calculation and constraint business rules from
                workflow).

                >
                >you might find that you need more fixture code to keep the tests
                >readable as a domain language. We've been using FIT for nearly a year
                >and, first, you have to let the tests develop over time as you get
                >used to them and, second, we have a lot of fixture code to get away
                >from any hit of their implementation. Using FitLibrary helps too.
                >
                >
                Through this year, I've been trying the approach of making the
                storytests reflect the domain and have the code follow. That is,
                applying domain driven design using the storytests. I'm moving towards
                making the storytests even more obviously about the domain and also
                minimising the fixtures that need to be written in that case, with
                FitLibrary. I've tried this on several projects, and it has been very
                effective. Of course, it may not be applicable in general. But it will
                be interesting to find out when it is and isn't.

                I will write up my experience with this approach in time. The things
                I've noticed so far:

                o Trying to express the domain (and work out what this is) has helped
                resolve and clarify issues that have been ongoing on a project
                o Expressing the domain more clearly helps the programmers understand
                better and aids in the discussions between customers and developers
                o Questions that arise in the domain code are sometimes best answered
                with extra examples (storytests)
                o Having the same terminology in the code and storytests really speeds
                up communication. Many of the discussions between customers and
                developers are around the names of things (is this a 'client name' or a
                'client name pattern'?) and their associations (Are the financial
                transactions associated with the customer or the account?)
                o Extracting calculation and constraint business rules is very effective
                for thinking about them and for reducing redundancy
                o On one project, the architecture was mostly technology focussed. The
                domain layer was a mess. The storytests are helping to focus on the
                domain, so it is treated as just as important
                o Subsets of storytests may be considered as representing a usecase, for
                those who want to think in those terms
                o There are different perspectives on a system, with their own
                storytests - eg, an installation or maintenance view. I suspect that the
                'domain' really includes everything that the customers want. So if the
                details of the UI are important to customers, a ubiquitous language for
                discussing/specifying the UI is needed
                o Storytests based on good concrete examples from the domain can be used
                beyond functionality testing. Eg, augmenting some storytests with
                'documentation' tables, etc, means that the detailed level of user
                documentation and help can be auto-generated with automated screen
                dumps. This allows for continuous development of documentation as a part
                of the development cycle.

                Cheers, Rick

                PS, I use storytests to drive into the code to a certain point and then
                switch into unit tests to drive the details, when I feel it's necessary.

                >S.
                >
                >
                >


                [Non-text portions of this message have been removed]
              • Heinrich Breedt
                ... then ... necessary. Do I understand it correctly by saying that the Fit Test and the Unit Test do not cover all the sourcecode by themselves, but together
                Message 7 of 18 , Nov 29, 2005
                • 0 Attachment
                  --- In extremeprogramming@yahoogroups.com, Rick Mugridge <rick@r...>
                  wrote:
                  > PS, I use storytests to drive into the code to a certain point and
                  then
                  > switch into unit tests to drive the details, when I feel it's
                  necessary.

                  Do I understand it correctly by saying that the Fit Test and the Unit
                  Test do not cover all the sourcecode by themselves, but together they
                  do?
                • Sam Gentile
                  Here s my current perspective on how FIT fits in -)) http://samgentile.com/blog/archive/2005/11/28/32138.aspx ... -- Sam Gentile INETA Speaker, Microsoft
                  Message 8 of 18 , Nov 29, 2005
                  • 0 Attachment
                    Here's my current perspective on how FIT "fits in"-))

                    http://samgentile.com/blog/archive/2005/11/28/32138.aspx


                    On 11/29/05, Heinrich Breedt <heinrichbreedt@...> wrote:
                    >
                    > --- In extremeprogramming@yahoogroups.com, Rick Mugridge <rick@r...>
                    > wrote:
                    > > PS, I use storytests to drive into the code to a certain point and
                    > then
                    > > switch into unit tests to drive the details, when I feel it's
                    > necessary.
                    >
                    > Do I understand it correctly by saying that the Fit Test and the Unit
                    > Test do not cover all the sourcecode by themselves, but together they
                    > do?
                    >
                    >
                    >
                    >
                    >
                    > 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
                    >
                    >
                    >
                    >
                    >
                    >
                    >


                    --
                    Sam Gentile
                    INETA Speaker, Microsoft MVP-Solutions Architect, UG Leader Beantown .NET
                    .NET Blog: http://samgentile.com/blog/
                    .NET Portal: http://samgentile.com/


                    [Non-text portions of this message have been removed]
                  • Hugo Garcia
                    ... Your quoted comment from the blog: It s a tool for facilitating discussions about the domain at the requirements and design levels. In this iteration, it
                    Message 9 of 18 , Nov 29, 2005
                    • 0 Attachment
                      On 11/29/05, Sam Gentile <sgentile@...> wrote:
                      > Here's my current perspective on how FIT "fits in"-))
                      >
                      > http://samgentile.com/blog/archive/2005/11/28/32138.aspx
                      >
                      >

                      Your quoted comment from the blog:

                      " It's a tool for facilitating discussions about the domain at the
                      requirements and design levels. In this iteration, it was the FIT
                      tests that sort of forced business and development into long, fruitful
                      discussions that fleshed out what it is we are really wanting as well
                      as designing. And it was so much more than anyone thought. There were
                      tremendous amounts of details in there that no one knew about until we
                      tried to write the FIT tests."

                      Is exactly why i belive in story testing.

                      -H
                    • Steven Gordon
                      I suspect that in most projects, neither the Fit Tests nor the Unit Tests would cover the UI-specific source code. It might be more useful to think of: - Unit
                      Message 10 of 18 , Nov 29, 2005
                      • 0 Attachment
                        I suspect that in most projects, neither the Fit Tests nor the Unit Tests
                        would cover the UI-specific source code.

                        It might be more useful to think of:
                        - Unit Tests as an executable specification of the isolated behaviour of
                        code units (such as objects);
                        - Fit Tests as an executable specification of the integrated behaviour of
                        these same code units, i.e. integration tests.


                        On 11/29/05, Heinrich Breedt <heinrichbreedt@...> wrote:
                        >
                        > --- In extremeprogramming@yahoogroups.com, Rick Mugridge <rick@r...>
                        > wrote:
                        > > PS, I use storytests to drive into the code to a certain point and
                        > then
                        > > switch into unit tests to drive the details, when I feel it's
                        > necessary.
                        >
                        > Do I understand it correctly by saying that the Fit Test and the Unit
                        > Test do not cover all the sourcecode by themselves, but together they
                        > do?
                        >


                        [Non-text portions of this message have been removed]
                      • Hugo Garcia
                        ... I agree, although, if your project is web based then it is possible to fashion a set of tests that are conceptually just another View. Were it gets hairy
                        Message 11 of 18 , Nov 29, 2005
                        • 0 Attachment
                          On 11/29/05, Steven Gordon <sgordonphd@...> wrote:
                          > I suspect that in most projects, neither the Fit Tests nor the Unit Tests
                          > would cover the UI-specific source code.

                          I agree, although, if your project is web based then it is possible to
                          fashion a set of tests that are conceptually just another View. Were
                          it gets hairy is when you try to story test a desktop GUI. More detail
                          of some thoughts and an approach to how to test the desktop GUI are
                          availbel in Chapter 32 of the Fit book. Strory testing GUI's can
                          become over complicated very quickly and the reason lies in the answer
                          to the question: Where is the "border" between the View and the Model?
                          Another point to consider is how much of the GUI are you testing?
                          Meaning, are you just testing the functionality of the GUI and are
                          aware that you should not test the structure or layout of the GUI?

                          -H
                        • Steven Gordon
                          ... That would depend on whether your organization believed it was worth the pain to implement and maintain an executable specification of the UI of an
                          Message 12 of 18 , Nov 29, 2005
                          • 0 Attachment
                            On 11/29/05, Hugo Garcia <hugo.a.garcia@...> wrote:
                            >
                            > On 11/29/05, Steven Gordon <sgordonphd@...> wrote:
                            > > I suspect that in most projects, neither the Fit Tests nor the Unit
                            > Tests
                            > > would cover the UI-specific source code.
                            >
                            > I agree, although, if your project is web based then it is possible to
                            > fashion a set of tests that are conceptually just another View. Were
                            > it gets hairy is when you try to story test a desktop GUI. More detail
                            > of some thoughts and an approach to how to test the desktop GUI are
                            > availbel in Chapter 32 of the Fit book. Strory testing GUI's can
                            > become over complicated very quickly and the reason lies in the answer
                            > to the question: Where is the "border" between the View and the Model?
                            > Another point to consider is how much of the GUI are you testing?
                            > Meaning, are you just testing the functionality of the GUI and are
                            > aware that you should not test the structure or layout of the GUI?
                            >
                            > -H


                            That would depend on whether your organization believed it was worth the
                            pain to implement and maintain an executable specification of the UI of an
                            application, and if so, what aspects/properties of the UI would be worth
                            specifying.

                            Most organizations come to the realization that no matter what your
                            executable specifications say, a story is still not acceptable until the
                            customer says it is, so the customer will be testing the UI when they decide
                            whether or not to accept each story.

                            Steve


                            [Non-text portions of this message have been removed]
                          • Hugo Garcia
                            ... I believe that the important thing to test is the interaction of the GUI with the domain model and not the visual representation of the GUI. If you want to
                            Message 13 of 18 , Nov 29, 2005
                            • 0 Attachment
                              >
                              > That would depend on whether your organization believed it was worth the
                              > pain to implement and maintain an executable specification of the UI of an
                              > application, and if so, what aspects/properties of the UI would be worth
                              > specifying.

                              I believe that the important thing to test is the interaction of the
                              GUI with the domain model and not the visual representation of the
                              GUI. If you want to test the visual representation then a scripting
                              tool would be more appropiate and not Fit. For example, you could have
                              a set of tests to that mimic entereing a list of names. On the first
                              run you create a List widget and and it passes all the test story
                              tests and unit tests. The important thing to test is that the widget
                              is updating your model properly. So although the input is through the
                              widget, the results of the story tests are based on your domain model
                              and not the state of the widget.

                              >
                              > Most organizations come to the realization that no matter what your
                              > executable specifications say, a story is still not acceptable until the
                              > customer says it is, so the customer will be testing the UI when they decide
                              > whether or not to accept each story.

                              But the customers don't like a List widget and they demand that you
                              change it to a Table widget. You go back to your test and change the
                              widget used in the tests and that should be your only change. You
                              refactor both the story tests and unit test for the different widget
                              and make them pass.

                              Lets say you use domain driven design and you have a full set of story
                              tests against the domain model. By using the above approach you reause
                              the same tests but add another layer though which the tests are
                              executed. Instead of the test interacting directly with the model, now
                              ther interact via the GUI on the model.

                              -H
                            • J. B. Rainsberger
                              ... This sounds like doing TDD with only acceptance tests, which some people do, but which I have not found generally helpful when I have tried it. ... 1. Pick
                              Message 14 of 18 , Nov 29, 2005
                              • 0 Attachment
                                Heinrich Breedt wrote:
                                > Hi,
                                >
                                > I have been using Nunit now for quite a while and i love TDD.
                                > I am now starting to use Fit, and now kinda wondering what my rhytm of
                                > programming should look like.
                                >
                                > Do I start with the User acceptance tests, make them work in the "glue"
                                > classes, and then start the unit tests?

                                This sounds like doing TDD with only acceptance tests, which some people
                                do, but which I have not found generally helpful when I have tried it.

                                > Seems logical, but i find that in order to make the Fit tests pass, i
                                > write quite a bit of code that is not under test, which i then put
                                > under test "after the fact". Makes me uncomfortable.
                                >
                                > Do i just leave the Fit Tests not working (not compiling) while a TDD
                                > the domain classes?
                                >
                                > Any thoughts?

                                1. Pick one row of one Fit table that doesn't pass yet.
                                2. Test-drive just enough code to make that example work, using NUnit to
                                write the usual programmer tests.
                                3. Wire up the Fit table to your code and see that it passes the first row.
                                4. Repeat.
                                --
                                J. B. (Joe) Rainsberger :: http://www.jbrains.info
                                Your guide to software craftsmanship
                                JUnit Recipes: Practical Methods for Programmer Testing
                                2005 Gordon Pask Award for contribution Agile Software Practice
                              • Jim Shore
                                ... How can I refuse an introduction like that? :) I ve written about my perspective on Fit usage on my blog, here:
                                Message 15 of 18 , Nov 29, 2005
                                • 0 Attachment
                                  Sam Gentile wrote:
                                  > Don't have much time now but I'm going to ask Jim Shore to comment here as
                                  > he has been teachig our team story-driven development using FIT and has a
                                  > lot of great perspective on it.More soon-)

                                  How can I refuse an introduction like that? :)

                                  I've written about my perspective on Fit usage on my blog, here:

                                  http://www.jamesshore.com/Blog/A-Vision-For-Fit.html

                                  What's not in that blog entry is the process I recommend for people to
                                  actually write the documents and code. What I'm about to describe isn't
                                  the only way--we're all still learning about how to best use Fit--but
                                  it's currently my favorite approach.

                                  Like Dale, I started out by using Fit in the same way that I use
                                  test-driven development. I took the first Fit example (not
                                  "storytest"--ick), made it pass, then moved on to the next one, etc.

                                  I encountered a big problem with this approach, though: I found that I
                                  stopped doing good TDD. "Storytest-driven development" blurred the line
                                  between Fit and unit tests and, as a result, I had far fewer unit tests
                                  than normal.

                                  That was fine at first, but as I refactored my code and changed my Fit
                                  documents, I lost confidence that my code was being tested. Also,
                                  refactoring tools aren't aware of Fit documents, so changes started to
                                  become painful.

                                  Since then, I've switched to another approach. Now I draw a very sharp
                                  distinction between Fit and TDD. Fit is a level higher than TDD--if TDD
                                  is 'red-green-refactor' then Fit is 'describe-demonstrate-develop' where
                                  "develop" includes all of TDD.

                                  1. Describe. In the Fit document, describe, in a short paragraph, part
                                  of the functionality that the software supports. (This should be done
                                  by business experts / product management / onsite customers.)

                                  2. Demonstrate. Provide some examples of the functionality, preferably
                                  examples that show the differences in possibilities. Sometimes only one
                                  or two examples is enough. (This should be done by business experts,
                                  possibly with help from testers and programmers.)

                                  3. Develop. Develop the functionality using TDD. Use the structure and
                                  terms of the examples to provide direction for the domain model as per
                                  "ubiquitous language" in Eric Evans' _Domain-Driven Design._ Use
                                  concepts from the examples to drive the creation of new types as per
                                  "whole value" in Ward Cunningham's _Checks Pattern Language._ Don't run
                                  Fit until this small increment of functionality is done. When it is,
                                  create the Fit fixture and hook it up. Use your Whole Value classes in
                                  preference to primitive types. Run the document and the paragraph's
                                  examples should pass. (This should be done by programmers.)

                                  4. Repeat. The next paragraph and set of examples in the Fit document
                                  may provide additional wrinkles and details on the basic functionality
                                  of the first paragraph.

                                  It's a bit late and I don't know if I'm describing myself well. It's
                                  easier in face-to-face conversation. With a whiteboard. :)

                                  The describe-demonstrate-develop approach assumes a bunch of things. It
                                  assumes that you're using Fit to drive discussion about the domain
                                  rather than as an exhaustive testing tool. It assumes that your
                                  business experts, not your testers, are providing the majority of the
                                  Fit direction and examples. It assumes the presence, and primacy, of a
                                  domain model. It assumes that Fit is being used to primarily to assist
                                  with complex domain rules rather than testing UI or database.

                                  This approach may be appropriate for those other ways of using Fit, but
                                  I think the biggest value of Fit today is in its ability to assist with
                                  complex domains and so I haven't used it for those other things.

                                  The above approach also assumes a particular way of structuring a Fit
                                  document that I seem to have invented (or re-discovered, or something).
                                  I guess you could call it "elaborating on a theme." In this approach,
                                  you start with a concept and describe the most basic case (with a few
                                  examples). Then you describe one special case or additional detail
                                  (with a few more examples). Then another. Then another. In the end,
                                  you have a large section of a document with perhaps five paragraphs
                                  (depending on how much detail you need to provide), each with its own
                                  small set of examples.

                                  You can see this approach in action in the Fit Specification which is
                                  part of the Fit download. Check out parse.html for the best example.
                                  It's a bit hard to read because it's all about parsing HTML, so here's a
                                  lightly edited version:

                                  === cut ===
                                  Major Section: HTML Document Parsing

                                  Fit parses the tables from HTML documents into a data structure. For
                                  example, in the following table, raw HTML is shown on the left and Fit’s
                                  view of the HTML is shown on the right. (Table cells are in brackets,
                                  rows are per line, and tables are separated by dashes.)

                                  [3 examples]

                                  Minor Section: Other HTML

                                  Everything but table structure and cell contents are ignored. The
                                  ignored portions are preserved so they can be output again later,
                                  exactly as they were read in.

                                  [3 examples]

                                  Even whitespace is preserved.

                                  [2 examples]

                                  Minor Section: Complicated Tables

                                  The colspan and rowspan attributes of table cells are also ignored, but
                                  jagged tables (tables with a varying number of cells in each row) are okay:

                                  [2 examples]

                                  Minor Section: Malformed HTML

                                  Tables that are missing "table," "tr," or "td" tags generate an error.

                                  [4 examples]

                                  Tables containing unclosed "table," "tr," and "td" tags also generate an
                                  error.

                                  [3 examples]

                                  However, excess closing tags don’t generate an error.

                                  [1 example]

                                  HTML mistakes that aren’t related to tables are ignored.

                                  [1 example]

                                  Major Section: Table Parsing
                                  [...etc...]
                                  === cut ===

                                  Here you can see how I'm taking a theme and elaborating on it.

                                  "Fit parses HTML tables. (example) Here's what we do about everything
                                  else (example). We deal with rowspan and colspan (example). We deal
                                  with malformed HTML (further detail, example, detail, example, detail,
                                  example, detail, example)."

                                  With this approach to writing Fit documents, it's very natural to take a
                                  single section, use TDD to develop it independently of Fit, then return
                                  to Fit to see the examples turn green. Fit helps drive the direction of
                                  development without driving the development directly like TDD does.

                                  You could probably use describe-demonstrate-develop with other ways of
                                  structuring Fit documents but this is what I'm currently using and
                                  recommending. :-)

                                  I hope this is helpful or interesting. As I look back, I don't feel
                                  like I've written very clearly. If you'd like me to clarify, please
                                  write. I'll check in on the mailing list and be sure to reply.

                                  Cheers,
                                  Jim

                                  > On 11/26/05, Stephen Freeman <smgfreeman@...> wrote:
                                  >
                                  >>On 25 Nov 2005, at 21:07, Dale Emery wrote:
                                  >>
                                  >>>I've been using a small story-test-driven-development cycle:
                                  >>>Write an acceptance test, write the code that passes it,
                                  >>>refactor. This isn't working for me. I've quickly learned that
                                  >>>it encourages me to think about classes too early. While I'm
                                  >>>writing acceptance tests, I want to focus on the story, and not
                                  >>>on classes.
                                  >>
                                  >>you might find that you need more fixture code to keep the tests
                                  >>readable as a domain language. We've been using FIT for nearly a year
                                  >>and, first, you have to let the tests develop over time as you get
                                  >>used to them and, second, we have a lot of fixture code to get away
                                  >>from any hit of their implementation. Using FitLibrary helps too.

                                  --
                                  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
                                • Rick Mugridge
                                  ... Yes, except when I take a shortcut and regret it later. My concern is not with cover, but with driving the design with the right amount of focus - I don t
                                  Message 16 of 18 , Nov 29, 2005
                                  • 0 Attachment
                                    Heinrich Breedt wrote:

                                    >--- In extremeprogramming@yahoogroups.com, Rick Mugridge <rick@r...>
                                    >wrote:
                                    >
                                    >
                                    >>PS, I use storytests to drive into the code to a certain point and
                                    >>
                                    >>
                                    >then
                                    >
                                    >
                                    >>switch into unit tests to drive the details, when I feel it's
                                    >>
                                    >>
                                    >necessary.
                                    >
                                    >Do I understand it correctly by saying that the Fit Test and the Unit
                                    >Test do not cover all the sourcecode by themselves, but together they
                                    >do?
                                    >
                                    >
                                    Yes, except when I take a shortcut and regret it later. My concern is
                                    not with cover, but with driving the design with the right amount of
                                    focus - I don't want to carry too much in my head at once. It's got the
                                    same quality for me whether I'm driving from storytests or unit tests
                                    that I've written. It's slightly different, somehow, when I'm developing
                                    from storytests that someone else has written.

                                    Cheers, Rick


                                    [Non-text portions of this message have been removed]
                                  • Dadi Ingolfsson
                                    Nice piece, Jim! I have some questions though: This method you use to structure your specifications/tests, as in parse.html in the Fit library, does it not
                                    Message 17 of 18 , Dec 1, 2005
                                    • 0 Attachment
                                      Nice piece, Jim! I have some questions though:

                                      This method you use to structure your specifications/tests, as in parse.html
                                      in the Fit library, does it not feel a little bit cluttered and complex?
                                      What I mean is, I would have thought that you would put the HTML parsing
                                      tests into a test suite, like in FitNesse, and then have a test in there for
                                      each of the cases? So you´d have:

                                      SuiteParsing
                                      TestGoodHtmlParsing
                                      TestOtherHtml
                                      TestWhitespaceIsPreserved
                                      TestComplicatedTables
                                      ...

                                      Maybe this is a bit too fine grained for some of the cases but...

                                      Similar to the tests you creates in xUnit you have a test method for each
                                      small piece of functionality in a unit. How is this different? It feels to
                                      me that you are sort of putting all the testing into a single method, if you
                                      see what I mean?

                                      Best regards,
                                      Dadi.

                                      Sam Gentile wrote:
                                      > Don't have much time now but I'm going to ask Jim Shore to comment here as
                                      > he has been teachig our team story-driven development using FIT and has a
                                      > lot of great perspective on it.More soon-)

                                      How can I refuse an introduction like that? :)

                                      I've written about my perspective on Fit usage on my blog, here:

                                      http://www.jamesshore.com/Blog/A-Vision-For-Fit.html

                                      What's not in that blog entry is the process I recommend for people to
                                      actually write the documents and code. What I'm about to describe isn't
                                      the only way--we're all still learning about how to best use Fit--but
                                      it's currently my favorite approach.

                                      Like Dale, I started out by using Fit in the same way that I use
                                      test-driven development. I took the first Fit example (not
                                      "storytest"--ick), made it pass, then moved on to the next one, etc.

                                      I encountered a big problem with this approach, though: I found that I
                                      stopped doing good TDD. "Storytest-driven development" blurred the line
                                      between Fit and unit tests and, as a result, I had far fewer unit tests
                                      than normal.

                                      That was fine at first, but as I refactored my code and changed my Fit
                                      documents, I lost confidence that my code was being tested. Also,
                                      refactoring tools aren't aware of Fit documents, so changes started to
                                      become painful.

                                      Since then, I've switched to another approach. Now I draw a very sharp
                                      distinction between Fit and TDD. Fit is a level higher than TDD--if TDD
                                      is 'red-green-refactor' then Fit is 'describe-demonstrate-develop' where
                                      "develop" includes all of TDD.

                                      1. Describe. In the Fit document, describe, in a short paragraph, part
                                      of the functionality that the software supports. (This should be done
                                      by business experts / product management / onsite customers.)

                                      2. Demonstrate. Provide some examples of the functionality, preferably
                                      examples that show the differences in possibilities. Sometimes only one
                                      or two examples is enough. (This should be done by business experts,
                                      possibly with help from testers and programmers.)

                                      3. Develop. Develop the functionality using TDD. Use the structure and
                                      terms of the examples to provide direction for the domain model as per
                                      "ubiquitous language" in Eric Evans' _Domain-Driven Design._ Use
                                      concepts from the examples to drive the creation of new types as per
                                      "whole value" in Ward Cunningham's _Checks Pattern Language._ Don't run
                                      Fit until this small increment of functionality is done. When it is,
                                      create the Fit fixture and hook it up. Use your Whole Value classes in
                                      preference to primitive types. Run the document and the paragraph's
                                      examples should pass. (This should be done by programmers.)

                                      4. Repeat. The next paragraph and set of examples in the Fit document
                                      may provide additional wrinkles and details on the basic functionality
                                      of the first paragraph.

                                      It's a bit late and I don't know if I'm describing myself well. It's
                                      easier in face-to-face conversation. With a whiteboard. :)

                                      The describe-demonstrate-develop approach assumes a bunch of things. It
                                      assumes that you're using Fit to drive discussion about the domain
                                      rather than as an exhaustive testing tool. It assumes that your
                                      business experts, not your testers, are providing the majority of the
                                      Fit direction and examples. It assumes the presence, and primacy, of a
                                      domain model. It assumes that Fit is being used to primarily to assist
                                      with complex domain rules rather than testing UI or database.

                                      This approach may be appropriate for those other ways of using Fit, but
                                      I think the biggest value of Fit today is in its ability to assist with
                                      complex domains and so I haven't used it for those other things.

                                      The above approach also assumes a particular way of structuring a Fit
                                      document that I seem to have invented (or re-discovered, or something).
                                      I guess you could call it "elaborating on a theme." In this approach,
                                      you start with a concept and describe the most basic case (with a few
                                      examples). Then you describe one special case or additional detail
                                      (with a few more examples). Then another. Then another. In the end,
                                      you have a large section of a document with perhaps five paragraphs
                                      (depending on how much detail you need to provide), each with its own
                                      small set of examples.

                                      You can see this approach in action in the Fit Specification which is
                                      part of the Fit download. Check out parse.html for the best example.
                                      It's a bit hard to read because it's all about parsing HTML, so here's a
                                      lightly edited version:

                                      === cut ===
                                      Major Section: HTML Document Parsing

                                      Fit parses the tables from HTML documents into a data structure. For
                                      example, in the following table, raw HTML is shown on the left and Fit’s
                                      view of the HTML is shown on the right. (Table cells are in brackets,
                                      rows are per line, and tables are separated by dashes.)

                                      [3 examples]

                                      Minor Section: Other HTML

                                      Everything but table structure and cell contents are ignored. The
                                      ignored portions are preserved so they can be output again later,
                                      exactly as they were read in.

                                      [3 examples]

                                      Even whitespace is preserved.

                                      [2 examples]

                                      Minor Section: Complicated Tables

                                      The colspan and rowspan attributes of table cells are also ignored, but
                                      jagged tables (tables with a varying number of cells in each row) are okay:

                                      [2 examples]

                                      Minor Section: Malformed HTML

                                      Tables that are missing "table," "tr," or "td" tags generate an error.

                                      [4 examples]

                                      Tables containing unclosed "table," "tr," and "td" tags also generate an
                                      error.

                                      [3 examples]

                                      However, excess closing tags don’t generate an error.

                                      [1 example]

                                      HTML mistakes that aren’t related to tables are ignored.

                                      [1 example]

                                      Major Section: Table Parsing
                                      [...etc...]
                                      === cut ===

                                      Here you can see how I'm taking a theme and elaborating on it.

                                      "Fit parses HTML tables. (example) Here's what we do about everything
                                      else (example). We deal with rowspan and colspan (example). We deal
                                      with malformed HTML (further detail, example, detail, example, detail,
                                      example, detail, example)."

                                      With this approach to writing Fit documents, it's very natural to take a
                                      single section, use TDD to develop it independently of Fit, then return
                                      to Fit to see the examples turn green. Fit helps drive the direction of
                                      development without driving the development directly like TDD does.

                                      You could probably use describe-demonstrate-develop with other ways of
                                      structuring Fit documents but this is what I'm currently using and
                                      recommending. :-)

                                      I hope this is helpful or interesting. As I look back, I don't feel
                                      like I've written very clearly. If you'd like me to clarify, please
                                      write. I'll check in on the mailing list and be sure to reply.

                                      Cheers,
                                      Jim

                                      > On 11/26/05, Stephen Freeman <smgfreeman@...> wrote:
                                      >
                                      >>On 25 Nov 2005, at 21:07, Dale Emery wrote:
                                      >>
                                      >>>I've been using a small story-test-driven-development cycle:
                                      >>>Write an acceptance test, write the code that passes it,
                                      >>>refactor. This isn't working for me. I've quickly learned that
                                      >>>it encourages me to think about classes too early. While I'm
                                      >>>writing acceptance tests, I want to focus on the story, and not
                                      >>>on classes.
                                      >>
                                      >>you might find that you need more fixture code to keep the tests
                                      >>readable as a domain language. We've been using FIT for nearly a year
                                      >>and, first, you have to let the tests develop over time as you get
                                      >>used to them and, second, we have a lot of fixture code to get away
                                      >>from any hit of their implementation. Using FitLibrary helps too.

                                      --
                                      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


                                      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
                                    • Jim Shore
                                      Hi, Dadi, ... I see your point and I would certainly do this if I felt I were writing tests. In this case, though, the testing aspect, while still important,
                                      Message 18 of 18 , Dec 1, 2005
                                      • 0 Attachment
                                        Hi, Dadi,

                                        Dadi Ingolfsson wrote:
                                        > This method you use to structure your specifications/tests, as in parse.html
                                        > in the Fit library, does it not feel a little bit cluttered and complex?
                                        > What I mean is, I would have thought that you would put the HTML parsing
                                        > tests into a test suite, like in FitNesse, and then have a test in there for
                                        > each of the cases? [...]

                                        I see your point and I would certainly do this if I felt I were writing
                                        tests. In this case, though, the testing aspect, while still important,
                                        is secondary.

                                        I'm more interested in providing a medium that's familiar to business
                                        experts so /they/ can write the examples. I use Fit to automatically
                                        check the examples and provide feedback, yes... but I still think of
                                        them as examples rather than tests, written by business experts from
                                        their perspective, using tools and approaches that are familiar to them.

                                        That's not to say that I put all of my Fit examples in a single
                                        document. Even the Fit spec, which is relatively small, has four files.
                                        I also use Word's automated 'table of contents' tool to provide a
                                        table of contents with links to various sections of the document.

                                        Still, managing a large set of Fit documents is a problem with Word.
                                        FitNesse does a great job of providing some tools to allow you to manage
                                        the overall document structure. If your business experts are
                                        comfortable with that approach, then by all means use it.

                                        The main thing I would recommend is to be careful of doing things that
                                        jeopardize the business experts' ownership of the Fit documents. I'll
                                        provide suggestions on layout but I won't make the changes myself. I've
                                        found that business experts are frequently surprised by how much careful
                                        thought is needed to flesh out "obvious" requirements into detailed Fit
                                        examples. They're all too often willing to relinquish ownership of the
                                        Fit documents to people less qualified than they are, and coming in to
                                        find everything in a different place could easily tip the scale.

                                        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
                                      Your message has been successfully submitted and would be delivered to recipients shortly.