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

Re: [XP] Test automation of data-driven code

Expand Messages
  • yahoogroups@jhrothjr.com
    Look at FIT. fit.c2.com www.fitnesse.org There s also an excellent book: FIT for Software Development by Rick Mugridge and Ward Cunningham. You re going to
    Message 1 of 5 , Mar 31 9:19 AM
    • 0 Attachment
      Look at FIT.

      fit.c2.com
      www.fitnesse.org

      There's also an excellent book: "FIT for
      Software Development" by Rick Mugridge
      and Ward Cunningham.

      You're going to need to make a firm
      decision between batch and FitNesse
      because the C# implementations are
      incompatible, at least at the level of
      writing fixtures.

      John Roth

      ----- Original Message -----
      From: "Ralph A. Mack" <ralph.at.maxware.mv.com@...>
      To: "extremeprogramming@yahoogroups.com"
      <extremeprogramming.at.yahoogroups.com@...>
      Sent: Friday, March 31, 2006 9:34 AM
      Subject: [XP] Test automation of data-driven code


      > Hello all,
      >
      > I am working on the web service layer of a configuration/provisioning
      > component of a larger product. We have been using automated unit
      > tests on this component since its inception.
      >
      > In our first release, we wrote a lot of code for the business rules.
      > Over time, we found that a lot of the rules and the measures used to
      > measure and enforce them, as well as the code to move data into and
      > out of the databse, looked pretty similar. (Obviously, we weren't
      > doing as much refactoring as we might in retrospect have done.)
      >
      > In our second release, we got rid of a *lot* of duplicate code by
      > encapsulating all of this in a common layer and driving what
      > mechanisms got used by metadata attached to the business objects. The
      > data used to control movement into and out of the database was stored
      > in C# attributes, while the data used to validate all the data
      > relationships was stored in tables in the database. The data we kept
      > in tables included data about some of the more complex stuff, like
      > references and qualified uniqueness. (Yes, we could have let the
      > database do some of that for us, but that meant we actually had to
      > attempt to perform an operation to find out if it would fly and we
      > wanted to pre-check everything and return to the user an itemized
      > list of *everything* that wouldn't fly in the data they sent us
      > before we actually attempted anything.)
      >
      > Surprise...we had tests for all that code we wrote in the previous
      > version which were scrapped with the code, and of course we had tests
      > for all of the *code* that we wrote in the new version. However, a
      > lot of the intelligence that was in the code before was now in data
      > so the quality of our testing ended up suffering. A lot more
      > situations got as far as the QA group, even if they were generally
      > really easy to fix and could in most cases even be fixed in the field.
      >
      > Overall, I feel pretty good about this latest release but, now that
      > it is about to ship and I am looking back, I keep wondering how we
      > could have reasonably applied test-first to the data. This is
      > especially interesting to me since I am now moving into lead on the
      > provisioning web services for another product.
      >
      > Thoughts? Opinions?
      > ++Ralph
      >
      >
      >
      >
      >
      > 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
      >
      >
      >
      >
      >
      >
      >
      >
    • Ralph A. Mack
      ... The tool space has really grown since my first post here (around #3200 and almost every March since then - seems I come up for air about once a year - We
      Message 2 of 5 , Mar 31 10:38 AM
      • 0 Attachment
        --- Quoth John Roth:
        >
        > Look at FIT.
        >
        > fit.c2.com
        > www.fitnesse.org
        >
        > There's also an excellent book: "FIT for
        > Software Development" by Rick Mugridge
        > and Ward Cunningham.

        The tool space has really grown since my first post here (around
        #3200 and almost every March since then - seems I come up for air
        about once a year - We got what, six digits now? Sheesh!).

        Thanks for the pointers. FITnesse has come up in a couple of other
        contexts now as well. It was mentioned, I think, in an ObjectMentor
        course my company is looking at using. Sounds like it might be a good
        time to get familiar with it.

        Ralph

        > You're going to need to make a firm
        > decision between batch and FitNesse
        > because the C# implementations are
        > incompatible, at least at the level of
        > writing fixtures.
        >

        That hurts a bit, as I like to run tests interactively when debugging
        but in the build stream when building. I'll still look into it,
        though.

        Ralph
      • Randy Coulman
        ... Fitnesse has a command-line test runner that you can use in your builds, so you should be fine that way. The decision really comes down to whether your
        Message 3 of 5 , Mar 31 11:08 AM
        • 0 Attachment
          On 3/31/06, Ralph A. Mack <ralph@...> wrote:
          >
          >
          > > You're going to need to make a firm
          > > decision between batch and FitNesse
          > > because the C# implementations are
          > > incompatible, at least at the level of
          > > writing fixtures.
          > >
          >
          > That hurts a bit, as I like to run tests interactively when debugging
          > but in the build stream when building. I'll still look into it,
          > though.


          Fitnesse has a command-line test runner that you can use in your builds, so
          you should be fine that way. The decision really comes down to whether your
          test-writers prefer using MS Word or equivalent to write HTML tests, or if
          they like using a Wiki like in Fitnesse.

          Randy
          --
          Randy Coulman
          rcoulman@...


          [Non-text portions of this message have been removed]
        • Ralph A. Mack
          ... Now that I ve looked at it, it looks like FITnesse is an acceptance test framework to run against a whole system, so it doesn t look like the kind of thing
          Message 4 of 5 , Mar 31 11:46 AM
          • 0 Attachment
            --- Quoth "Randy Coulman":
            > Fitnesse has a command-line test runner that you can use in your
            > builds, so you should be fine that way. The decision really comes
            > down to whether your test-writers prefer using MS Word or equivalent
            > to write HTML tests, or if they like using a Wiki like in Fitnesse.

            Now that I've looked at it, it looks like FITnesse is an acceptance
            test framework to run against a whole system, so it doesn't look like
            the kind of thing I'd be running against my code or SQL scripts after I
            run the script to repopulate the local database on my development box
            but before I checked them into the common build.

            ++Ralph
          • yahoogroups@jhrothjr.com
            From: Ralph A. Mack To: extremeprogramming@yahoogroups.com
            Message 5 of 5 , Mar 31 12:18 PM
            • 0 Attachment
              From: "Ralph A. Mack" <ralph.at.maxware.mv.com@...>
              To: "extremeprogramming@yahoogroups.com"
              <extremeprogramming.at.yahoogroups.com@...>
              Sent: Friday, March 31, 2006 12:46 PM
              Subject: Re: [XP] Test automation of data-driven code


              > --- Quoth "Randy Coulman":
              >> Fitnesse has a command-line test runner that you can use in your
              >> builds, so you should be fine that way. The decision really comes
              >> down to whether your test-writers prefer using MS Word or equivalent
              >> to write HTML tests, or if they like using a Wiki like in Fitnesse.
              >
              > Now that I've looked at it, it looks like FITnesse is an acceptance
              > test framework to run against a whole system, so it doesn't look like
              > the kind of thing I'd be running against my code or SQL scripts after I
              > run the script to repopulate the local database on my development box
              > but before I checked them into the common build.

              It looks like that, doesn't it? Lots of people take that first
              impression away and don't look further.

              It's actually a customer level specification tool that can also
              be used for acceptance testing.

              One of the hardest habits to break when using it is the notion
              that you should do "end-to-end" testing or "workflow" testing.
              Sure, both of them have their place in a good testing program.
              FIT/FitNesse is very good at extracting business rules and
              testing them in isolation, and then rolling them up into workflow
              tests.

              Unfortunately, there aren't a huge number of examples of
              actually doing the rollup, outside of the FIT Book.

              John Roth


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