Skip to content

Joseph Wilk

← @Leancamp Session Ideas

My feedback

1 result found

  1. Invitation to the test- & hypothesis-driven: What to test and how to test it. HDD meets TDD?

    12 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    6 comments  ·  Leancamp - Session Ideas » London 2  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Joseph Wilk supported this idea  · 
    An error occurred while saving the comment
    Joseph Wilk commented  · 

    Interesting thought. I'm still forming ideas about shared lessons but perhaps if I got down some of the aspects I feel important in TDD we might extract something.

    One of TDDs key aspects is that you express in plain English the behaviour of a unit before the unit exists. What makes that even stronger is you pair on writing the test. So this forces very early on a discussion ("should it really do that?").

    In TDD we also often use a ping pong style pairing. One person writes a test and then the other person has to make that test pass and so on. Again this forces discovering unknowns, as the person writing the code does not have the same mental model as the person who wrote the test.

    There is a mentality of failing fast and making the smallest possible step in order to complete the test. Often to the scale of doing something very quick and dirty and improving as you build further tests.

    One key difference I see is that with TDD the tests persist, and provide useful feedback throughout the lifetime of the units. Every hypothesis is validated upon every change. The tests often provide a form of documentation for people to understand how something works.

    Making things easy to test forces us to change the way we build our software. It forces the principles of isolating external dependencies, avoiding coupling between different units, working in small composable units. TDD helps us discover the smells of bad design in our system.

Feedback and Knowledge Base

(thinking…)