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
    ... Because it *is* test-driven development. TDD *does* work with well- defined problems -- for example, creating an implementation of an existing interface.
    Message 1 of 67 , Nov 2, 2008
      On Nov 1, 2008, at 3:27 PM, J. B. Rainsberger wrote:
      > On Wed, Sep 3, 2008 at 10:44 AM, John A. De Goes <john@...>
      > wrote:
      > >> 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.
      >
      > Yes, but then you call it "test-driven development", which it clearly
      > is not. Why confuse people?
      >


      Because it *is* test-driven development. TDD *does* work with well-
      defined problems -- for example, creating an implementation of an
      existing interface.

      In such cases, TDD doesn't contribute to the design of the public API,
      but may affect the design of the private implementation details.

      You really should have watched the tutorial before making such comments.

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