3 ms·

I got turned off from TDD in my senior year getting my CS degree. During class, the teacher taught us TDD, using the Test-Code-Refactor loop. Then he wanted u

I got turned off from TDD in my senior year getting my CS degree. During class, the teacher taught us TDD, using the Test-Code-Refactor loop. Then he wanted us to write an implementation of Conway's Game of Life using TDD. As the students were doing it, he was doing it as well. After the lesson but before the exercise, I thought "This looks tedious and looks like it would make coding take far longer than necessary" and just wrote the Game first, then wrote a couple dozen tests. Took me probably about 45 minutes. At that point, I looked up on the projector and saw the teacher had barely done much more than having a window, a couple buttons, and some squares drawn on it, and a dozen tests making sure the window was created, buttons were created, clicking the button called the function, and that the calls to draw squares succeeded. What really bothers me about "true" TDD (and TFA points this out), is that if you're writing bare minimum code to make a unit test pass, then it will likely be incorrect. Imagine writing an abs() function, and your first test is "assert (abs(-1) == 1)". So you write in your function "if (i == -1) return 1". Congrats, you wrote the bare minimum code. Tadaa! TDD!

gnulinux 4y ago
I'm really sorry but these kind of "I mocked a simple program in 45 mins when my TDD practicing counterpart took longer" comments mean nothing. The code is never written once and done. If you were maintaining that code for the next 6 years and there was no rush to ship it, it absolutely doesn't matter how fast it was written in the first place. I would much rather take code that was written better in 6 hours, than bad code written in 45 mins. I'm not saying you wrote bad code, but time to ship, in general, rarely matters in this context.
- tester756 4y ago
  >If you were maintaining that code for the next 6 years and there was no rush to ship it, it absolutely doesn't matter how fast it was written in the first place. Unfortunately that's not how software is written. >I would much rather take code that was written better in 6 hours, than bad code written in 45 mins. I'm not saying you wrote bad code, but time to ship, in general, rarely matters in this context. I disagree, time is not the best proxy for good code. 10x engineer will probably write way better code in 45mins than -10x engineer in 6h.

gnulinux 4y ago

I'm really sorry but these kind of "I mocked a simple program in 45 mins when my TDD practicing counterpart took longer" comments mean nothing. The code is never written once and done. If you were maintaining that code for the next 6 years and there was no rush to ship it, it absolutely doesn't matter how fast it was written in the first place. I would much rather take code that was written better in 6 hours, than bad code written in 45 mins. I'm not saying you wrote bad code, but time to ship, in general, rarely matters in this context.

tester756 4y ago
>If you were maintaining that code for the next 6 years and there was no rush to ship it, it absolutely doesn't matter how fast it was written in the first place. Unfortunately that's not how software is written. >I would much rather take code that was written better in 6 hours, than bad code written in 45 mins. I'm not saying you wrote bad code, but time to ship, in general, rarely matters in this context. I disagree, time is not the best proxy for good code. 10x engineer will probably write way better code in 45mins than -10x engineer in 6h.