Uncle Bob on DHH: Monogamous TDD

Re:Uncle Bob on DHH: Monogamous TDD by pjmlp on Monday April 28, 2014 @09:55AM (#7659932)

> UBob doesn't even tread into the crux of the matter, which is that code style and system architecture bent to the needs of testing becomes a ball of mud (though "testable") faster than code written without this consideration

Not to mention that GUIs, algorithms, stored procedures and a lot more other types of architectures are impractical to write, if at all, using TDDs approaches.

I never saw a way that could convince me to use it in such cases.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by humanrebar on Monday April 28, 2014 @10:27AM (#7660124)

I'm with you on testing GUIs and (mostly) stored procedures. I would add low-level interfaces (hardware, OS, third-party library implementations) to that list.

Algorithms are certainly testable with TDD though. In fact, they're probably the easiest thing to test. Maybe I don't understand what you mean by algorithm, but things that can be expressed mathematically (sorting, searching, decision trees) are very straightforward to test. Tests can even be reused to verify multiple algorithmic approaches to the same problem.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by pjmlp on Monday April 28, 2014 @10:33AM (#7660171)

> Maybe I don't understand what you mean by algorithm ...

I mean using TDD to specify:

- memory layout of the internal data structures

- O() access times

- cache friendliness

- concurrency

I see how one can test them in a unit test approach with whiteboard design and such, but not in a "write test, fail, write code, success" cycle that is usually sold on conferences.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by humanrebar on Monday April 28, 2014 @11:34AM (#7660623)

Unit testing would let you validate the correctness of the code.

As far as improving performance characteristics, the argument is that unit testing helps indirectly by improving awareness of the behavior of your system. Having a good idea of where there aren't bugs will let you be more aggressive in refactoring to improve things like performance characteristics.

Sun Tzu:

If you know your enemies and know yourself, you will not be imperiled in a hundred battles... if you do not know your enemies nor yourself, you will be imperiled in every single battle.

...if it's not clear, you are your code and bugs are enemies. It's all about mitigating risk through better understanding of your code base.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by parasubvert on Monday April 28, 2014 @04:30PM (#7662768)

TDD doesn't preclude one from doing whiteboard design and thinking things through. It just asks that you write a test case before you write your code.

It's sort of like enabling the feedback of a REPL to any language. Why wouldn't you write a test case to test the O() access time of a function ahead of time? Or test the memory layout of a data structure?

Seems to me those are great examples of tests I would write to help me flesh out the results I want, before I go and implement it. They help one specify _exactly_ what they want.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by dragonwriter on Monday April 28, 2014 @04:37PM (#7662840)

> Why wouldn't you write a test case to test the O() access time of a function ahead of time?

Because asymptotic limits are a lot easier to verify analytically than empirically. You can, of course, easily test the actual performance characteristics under specific conditions, but that's different than testing the asysmptotic limit.

Of course, TDD doesn't preclude analytically verifying those things that can be analytically verified.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by ciniglio on Monday April 28, 2014 @10:38AM (#7660204)

Testing algorithms is easy, yes, but it's usually not clear that TDD would lead you to design the optimal algorithm.

[ Parent | on HN ]

Re:Uncle Bob on DHH: Monogamous TDD by humanrebar on Monday April 28, 2014 @11:23AM (#7660522)

It would not, but good tests will let you verify the correctness of the algorithm without deploying your software to customers. Which frees you up to try more experimental things without ruining the experience of the users.

[ Parent | on HN ]