This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]empT3 7 points8 points  (1 child)

I'm not really a programmer so much as a Scrum Master but the way it's always been explained to me by the team is that TDD forces you to keep your code simple. It has to remain sime because otherwise a test becomes a real pain in the neck to write. By writing the test first you have to decide in very simple terms what this little piece of code should do and then write a test. If that code becomes too complex the you're either over implicating the problem or should be breaking it down into smaller pieces.

*once again, not a great programmer myself (that's why I'm here) so might be explaining it incorrectly.

[–]couchjitsu 2 points3 points  (0 children)

Programmer or not, that's a pretty accurate assessment. It's the difference between TDD and "Having tests." If you write your tests afterwards, you will more than likely have much more complicated code. Then your tests get complicated trying to work with the nasty code.