Re: Paralyzed by TDD

kj wrote:
> I've read the Beck book (TDD by Example)
>

Hi kj,

Great book, I love it.

I've done my own brand of TDD for 20 years but I really enjoy this
book, especially part III.

> , but I still can't make
> TDD work for me.
>

Use pair programming.

I'll do a bit below ...

> Here's a concrete programming task I'd like to solve using TDD,
> but I can't even get started:
>
> Given a directed graph (digraph) and a vertex in that graph,
> construct a pre-order DFS iterator to enumerate all the predecessors
> of the input vertex in the input digraph. (There are no implementation
> for digraphs and vertices. The problem entails implementing whatever
> classes are required to fulfill the stated task.)
>
> I.e., at the end of this I'd like to be able to write something like:
>
> Iterator p = d.predecessors(v);
> while ( !p.hasNext()) {
> Object w = p.next();
> // do something with w
> }
>
> ...where d and v are digraph and vertex objects, respectively. (I've
> shown "predecessors" as a factory method in the Digraph class, but
> this is just for illustration purposes; the question of which class
> is responsible for constructing such an iterator is also an open
> design question.)
>
> If I attempt to follow the procedure described by Beck, I can come
> up with a grand total of one (1) test:
>
> public void testDigraph() throws Exception {
> Digraph d = new Digraph();
> }
>

Ok, this is not a test ;-) You need to test something, like
assertTrue (d.isEmpty())

We can now just fake isEmpty() or build a real graph with Edge and
Vertex objects.

When I'm stuck I try *several* approaches if all else fails I go back
to the story. In this case it said "we want a digraph".

Ok, so "let there be a digraph" and then we can test if it is good.

Remember tests do not come first, the story does. Tests are but a
means.

> ...which I can "bring to green" trivially with
>
> public class Digraph {
> }
>

"Fake it until you make it" is great but not always. In this case I'd
rather build a crude graph first.

Part III of TDD lists many other patterns for progress.

>
> OK, now what? At this point, if I try to follow TDD as described
> by Beck, I'm paralyzed. I.e., in his book Beck implies that at
> this point I must come up with some small test to perform next,
> but no matter how I look at this, I don't see how I can avoid
> tackling much larger problems than can be tested with a simple
> single test.
>

I would build the very simple things first, Vertex, Edge, then Digraph.

Once we can build a graph we'll think about the next step.

> Would someone be willing to play along with me here and tell me
> what the next test would be?
>

Ok, I'll have a go.

Starting with a fraction of the story "we want a Digraph".

// Build Digraph but first we need

// 1. Vertex objects
Vertex v1 = new Vertex(...)
Vertex v2 = new Vertex(...)
Vertex v3 = new Vertex(...)

// 2. Edges
Edge e1 = new Edge(v1, v2)
Edge e2 = new Edge(v2, v3)

// 3. NOW attach to graph
Digraph g = new Digraph ()
assertTrue (g.isEmpty()) // fake for now

g.addEdge (e1)
g.addEdge (e2)

// 4a. TEST.
/*
* Problem, I don't know how to test?
* So let's break it up in to smaller tests.
*/

Vertex foundV;
foundV = g.findVertex (v1)
assertTrue( foundV.equals (v1) )

foundV = g.findVertex (v2)
assertTrue( foundV.equals (v2) )
....

// 4b. Test edges
Edge foundE;

foundE = g.findEdge (e1)
assertTrue( foundE.equals (e1) )

foundE = g.findEdge (e2)
assertTrue( foundE.equals (e2) )

/*
* This reminds me of AssertFirst on page 128 in TDD.
*
* We sort of work backwards.
* We want a result but first we need 'y' but prior to that we need 'x'
*/

NOTES

There's probably nothing do break in Edge and Vertex so nothing to test
until we get to Digraph. (Otherwise test them too).

Maybe now we can do the big test?

Digraph referenceGraph ...
Digraph g ...
assertTrue ( g.deepEquals (referenceGraph) ) OR
assertTrue ( Digraph.deepEquals (g, referenceGraph ))

This requires a full structural test with iterators, graph walkers
whatever ....

SUMMARY

At this point we should be able to create a graph. A GREAT start.

Have a coffee break and then let's clean it all up.

Later we can think about algorithms and graph usage situations.


> Thanks!
>
> kj
> --
> NOTE: In my address everything before the first period is backwards;
> and the last period, and everything after it, should be discarded.

Can Agile/TDD help discover minute algorithms and patterns? Yes.

We can break this story down and re-invent graphs but that would be a
completely different story. Here I'm just reusing known computer
science and avoiding the "project within a project" scenario.

Hope that helps,
Cheers.

.

Relevant Pages

  • Paralyzed by TDD
    ... TDD work for me. ... Here's a concrete programming task I'd like to solve using TDD, ... Given a directed graph (digraph) and a vertex in that graph, ... If I attempt to follow the procedure described by Beck, ...
    (comp.object)
  • Re: Paralyzed by TDD
    ... >TDD work for me. ... >Here's a concrete programming task I'd like to solve using TDD, ... >Given a directed graph and a vertex in that graph, ... >of the input vertex in the input digraph. ...
    (comp.object)
  • Re: Paralyzed by TDD
    ... > I've read the Beck book, ... > TDD work for me. ... > of the input vertex in the input digraph. ... - What behaviour do you expect from an empty Digraph? ...
    (comp.object)