Hacker News Reader

Comment by Joker_vD | Hacker News Reader

The fact that some people really argue that TDD produce better designs... sigh. Here, look at this [0] implementation of Dijkstra's algorithm, written by Uncle Bob himself. If you think that is well-designed (have you ever seen weighted graphs represented like this?) then, well, I guess nothing will ever sway your opinion on TDD. And mind you, this is a task that does have what a top comment in this very thread calls a "well defined spec".

[0] https://blog.cleancoder.com/uncle-bob/2016/10/26/DijkstrasAl...

View on HN

What the actual fuck… I only got two pages down and already found several red flags that I would never accept in any code review. Not the least of which is that when querying an edgeless graph for the shortest path from node A to node Z, “the empty path of length 0” is the exact opposite of a correct answer.

So thanks for the link, I guess. I’ll keep this as ammunition for the next time someone quotes Uncle Bob.

Damn, indeed. The Uncle Bob people (or, really, any "this book/blog post/whatever says to do technique x" people) are my absolute least favorite. This is a good riposte. Or, alternatively, if they don't understand why it's bad then you know they're a shit coder.

In my personal experience, TDD helps me produce better designs. But, thinking also helps me produce better designs, too. There's a lot of documentation that Creepy Uncle Bob isn't the most thoughtful person, and I think this blog post says much more about him than about TDD.

The code is definitely a horrow show.

Can you link to an implementation you would consider great?

I would just like to compare them. I too find Uncle Bobs “clean code” book very much overrated.

My understanding of the “design” aspect of TDD is, that you start from client code and create the code that conforms to your tests. Too often I worked in a team with other developers and I wanted to use what they wrote, and they somehow coded what was part of the spec, but it was unusable from my code. Only because I was able to change their code (most often the public API) I was able to use it.

It stores it as a collection of edges? Why not use adjacency list representation?

You iterate through all of the edges every time to find a nodes neighbors?

idk, this code just looks terrible to me.

But TDD (the main topic being discussed here) has nothing to do with that, right? I mean, how on earth is TDD going to help you decide between a) using a simple data structure like a collection and b) a more sophisticated data structure like the adjacency list, if you have no idea what an adjacency list is?

Yeah I was only commenting on what was being discussed in this particular subthread about whether this was good code/design.

But now you have the tests to be able to refactor the implementation and improve it.

I’ve been in too many projects where devs almost never write tests. They cut corners by neither writing tests nor documentation because of time pressure. Then the code breaks in production with simple edge cases like NullPointerException and they need to fix it, so they don’t have time to write unit tests for the next feature. And it’s definitely harder to write tests after you implemented something.

Reply on news.ycombinator.com