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

Re: [XP] What's up with Rails?

Expand Messages
  • Phlip
    ... The general goal is the test fails in a way that tells us how to upgrade the code. Hopefully via a clear diagnostic. ... It is unfortunate that the test
    Message 1 of 55 , Jan 5, 2007
    • 0 Attachment
      dnicolet99 wrote:

      > > assert_xpath 'Statement[1]//ArgumentList[1]' do |node|
      > > assert_equal
      > > '/wiki/display_iframe?page_name=WikiTestPage&ypath=//test_uncle_wiggly',
      > > assert_argument(1)
      > > end

      > (a) ...to ensure certain arguments are present and that they have
      > certain values?

      The general goal is the test fails in a way that tells us how to
      upgrade the code. Hopefully via a clear diagnostic.

      > (b) ...to verify the conditions listed in (a) and that the arguments
      > appear in a specified order?

      It is unfortunate that the test currently tests syntax, not semantics.
      No CGI parser in the world cares what order you provide arguments.
      Unfortunately, the test does, so it does not yet match the semantics
      of the target situation.

      > (c) ...to verify the conditions listed in (b) and that the formatting
      > / escape sequences / miscellaneous details conform precisely to the
      > sequence of bytes given as the expected value?
      >
      > It seems to me the first version of the test is asserting (c). If that
      > is the purpose of the test, then rather than adjusting the assertion
      > to match the actual output from the application, we would want to
      > modify the application to output the asserted value.

      You can't do that. The test was given as an example of TDD failing to
      match a legacy code situation. Greenfield TDD code is always much
      easier to test-first.

      As I write more tests like this, I would start using CGI::escape in
      them. It would help the tests lead, by demanding the correct escapes
      and such.

      > If the purpose of the test is (a), and the behavior of the system is
      > not so variable that arguments are liable to come back in a different
      > order

      As a matter of fact, the target system is just that variable. Ruby
      stores its hash keys in virtual memory at various addresses. Two runs
      of the same program can reveal these keys in different orders.

      > then the pragmatic adaptation you made in the second version of
      > the test seems perfectly appropriate to the goal. In that case, there
      > really is no problem here.

      To approach TDD, you must invest in test-side code that helps you
      predict (or ignore) intermediate behavior correctly. Then you can
      start focusing on tests that improve the semantics of your target
      code, not just the syntax.

      --
      Phlip
      http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
    • Kent Beck
      Charlie, Having coined the phrase, I can speak with a fair amount of certainty that test-first has always been a part of TDD. When I first started writing
      Message 55 of 55 , Jan 12, 2007
      • 0 Attachment
        Charlie,

        Having coined the phrase, I can speak with a fair amount of certainty that
        test-first has always been a part of TDD. When I first started writing tests
        first, I focused on that aspect. When I started writing the TDD book, I
        realized that what I did was really the combination of test-first and
        incremental design, and that either component technique could be used on its
        own.

        Regards,

        Kent Beck
        Three Rivers Institute


        _____

        From: extremeprogramming@yahoogroups.com
        [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Charlie Poole
        Sent: Tuesday, January 09, 2007 3:11 PM
        To: extremeprogramming@yahoogroups.com
        Subject: RE: [XP] Re: What's up with Rails?



        > > >using automated tests to drive all aspects of development, at all
        > > >scales.
        >
        > Not so many years ago, the term TDD didn't necessarily imply
        > "test- first". Fortunately, like other agile concepts and
        > practices, ideas about just what TDD "is" have evolved over
        > time. Today, TDD implies test-first. There is no need to
        > invent another TLA to describe test- first development.

        Interesting... In my own personal experience, I've only run into
        the notion of TDD without doing the tests first fairly recently,
        as an error in interpretation on the part of those who weren't
        around when TDD grew - as I believe it did - out of test-first.

        As a matter of historical curiosity, I'd love to see some
        examples of the early use of TDD without "firstness"

        Charlie







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