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

Re: [XP] TDD Like You've Never Seen it Before

Expand Messages
  • John A. De Goes
    Hi Ron, ... We have a demo server you can use. It s not designed for production work, but if you just want to do a little coding here and there, it would fit
    Message 1 of 67 , Sep 3, 2008
    • 0 Attachment
      Hi Ron,

      On Sep 3, 2008, at 8:03 AM, Ron Jeffries wrote:
      > Hello, John. On Tuesday, September 2, 2008, at 7:12:10 PM, you
      > wrote:
      >
      > > A short screencast showing myself and two other developers TDD'ing a
      > > Stack in the Java programming language:
      >
      > > http://www.vimeo.com/1653402
      >
      > Interesting. Makes me wish we could make UNA work.
      >

      We have a demo server you can use. It's not designed for production
      work, but if you just want to do a little coding here and there, it
      would fit the bill.

      With the demo server, you would only have to install the client, which
      is a breeze and takes all of 60 seconds. No configuration is
      necessary, because the client already knows how to find the server.
      Let me know if you're interested.

      > 1. You started with about a million lines of code before
      > the first test. Or 15.
      >

      Sure. Ordinarily I wouldn't recommend this approach, but a stack is a
      very well-defined problem, and we agreed on the methods to develop
      beforehand. By writing the signatures upfront, we get that grunt work
      out of the way and can focus on the red/green/refactor cycle.

      We would have done it differently if either (1) the problem was not
      well-defined, or (2) UNA could automatically create missing methods.

      > 2. Is there some skipped material? It seemed that a method
      > magically appeared without being typed in on the screen.
      > But maybe I dozed off.
      >

      There's no skipped material, but due to the resolution limitations,
      sometimes the video pans to one location even though stuff is
      happening elsewhere. And with 3 developers, stuff happens quite fast.
      For example, I usually inserted the test method, by typing 'test' and
      hitting Command + I, which inserts a JUnit test. Usually before I even
      finished typing the name of the test, Alex or Misha were busy coding
      its innards. Look away for 3 seconds and you could miss a whole method.

      > Definitely interesting. Pretty close to what I'd expect in TDD.
      > Close enough, in fact.
      >
      > Neat.
      >


      Thanks. Your feedback makes me want to do another one on a more open-
      ended problem, which would be more representative of TDD in the wild.
      It would probably last longer, and therefore have a smaller audience,
      but would help showcase the design benefits of TDD.

      Regards,

      John A. De Goes
      N-BRAIN, Inc.
      http://www.n-brain.net
      [n minds are better than n-1]
    • Jeff Grigg
      ... I m not sure about the good introduction training aspect of starting with the target class and method shells, and then writing tests. I would consider
      Message 67 of 67 , Nov 13, 2008
      • 0 Attachment
        --- "John A. De Goes" <john@...> wrote:
        > A short screencast showing myself and two other developers
        > TDD'ing a Stack in the Java programming language:
        >
        > http://www.vimeo.com/1653402
        >
        > I think it makes a good introduction to test-driven
        > development, [1] and shows how following TDD strictly
        > leads to test coverage of all code paths. You can
        > download the source code from
        > http://www.n-brain.net/outbox/una-tdd-stack.zip

        I'm not sure about the "good introduction" training aspect of starting
        with the target class and method shells, and then writing tests. I
        would consider this an "acceptable" TDD approach, but not pure, and
        not the approach I take when teaching TDD.

        Overall, I would call it a successful TDD session. And an interesting
        tool.

        _ _ _ _ _


        I'll push the refactoring another two or three steps:

        #1. I don't like duplicate data.

        So I killed the 'private volatile int size;' property, giving...

        public int size() {
        int size = 0;
        for (Node<T> node = head; node != null; node = node.getNext())
        ++size;
        return size;
        }

        public boolean isEmpty() {
        return (head == null);
        }

        [and a few more deleted lines]

        If you want efficient, add a test for it. (...that 'Node.getNext()'
        isn't called N times.)


        #2. Simplify 'push'...

        from
        public void push(T value){
        if (head == null) {
        head = new Node<T>(value, null);
        }
        else {
        Node<T> oldHead = head;
        head = new Node<T>(value, oldHead);
        }
        }

        to
        public void push(T value){
        head = new Node<T>(value, head);
        }


        #3. Delete the default constructor. Java generates one.

        IE:
        public Stack() {
        }


        There. Better now? ;->
      Your message has been successfully submitted and would be delivered to recipients shortly.