Skip to main content
Software Engineering

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

6
  • I don't love the example, but I do agree with the premise; test-first methodologies only make sense when you're able and willing to do at least some up-front design. In fact you really tend to need a skeleton domain model, or at least a sizable chunk of one. Commented Jun 15, 2011 at 18:27
  • 5
    There's no up front design here. None of the classes in the test need to exist yet. The design happens in the test, THEN they are created to make the test pass. Commented Jun 15, 2011 at 19:05
  • Could you elaborate on "Before you write your first test, you have to think about what your first bit of functionality is going to be, and what your program would look like if that functionality were working."? How much should I work out before starting? At what point am I over-designing and losing the benefit of letting my unit tests drive my design? I assume I don't want class diagrams, that should be driven by refactoring, right? But this example sounds like "Have an idea, invest 15 seconds of thought, then write a test." Is that really all I want to do? Commented Jun 15, 2011 at 19:59
  • 2
    @Ethel Yes, that's about as much thought as I would recommend putting into it (both in the example here and in general). Figure out something testable, that leads you toward the product you want, and then write a test for it. Commented Jun 15, 2011 at 20:05
  • 1
    How it works on a team is a bigger and different question. And TDD itself doesn't have a lot to say about coordinating team work. Pair Programming and the Planning Game can help with that; within the context of what you've planned, TDD still applies. jamesshore.com/Agile-Book/the_planning_game.html Scrum, too, has something to say about how to plan a team's work. Commented Jun 15, 2011 at 22:54