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

115574RE: [XP] Fit and Unit Tests, how to go about it

Expand Messages
  • Dadi Ingolfsson
    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:


      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,

      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:


      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

      [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
      === 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.


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

      ad-free courtesy of objectmentor.com
      Yahoo! Groups Links
    • Show all 18 messages in this topic