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

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

Expand Messages
  • J. B. Rainsberger
    ... Yes, but then you call it test-driven development , which it clearly is not. Why confuse people? -- J. B. (Joe) Rainsberger :: http://www.jbrains.ca Your
    Message 1 of 67 , Nov 1, 2008
    • 0 Attachment
      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?
      --
      J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      Your guide to software craftsmanship
      JUnit Recipes: Practical Methods for Programmer Testing
      2005 Gordon Pask Award for contribution Agile Software Practice
    • 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.