4 ms·

I don't understand why people keep on painting it black or white, like either you use TDD or no tests at all? You can implement a feature and then write a test

I don't understand why people keep on painting it black or white, like either you use TDD or no tests at all? You can implement a feature and then write a test afterwards to test if it works as planned. It'll work just as good as TDD. IMHO the main benefit of tests is when refactoring at a later time, while during the initial prototyping and developing process they're usually just telling you the obvious (you didn't return the expected value... yeah, I know, I didn't finish the freakin' method yet, give me a break..)

eesmith 9y ago
Because if you are for a certain approach then it's easier to put all alternatives in the same category, then pick one as the antithesis, show that your approach is better, and conclude that everything which isn't your approach is worse. You'll see that it's mostly TDD people who treat things as either "test first" or "test last", where "test last" occurs after all development. As another example, agile people say there's "agile" and "waterfall", even though there are many software development approaches other than those two.
- marcosdumay 9y ago
  Or, in other words, those people are shooting for political dominance and don't care about truth. I am quite sure it is an inconscient bias, but it's tiring to keep listening those dishonest arguments everywhere.
PaulKeeble 9y ago
Some approaches aren't very testable and produce either very bad tests or can't be tested at all.
hdi 9y ago
The problem I've seen come out of test after is complete implementations with 0 tests. People will just forget to do it! Especially if working on few different areas of the code at the same time. And it happens often enough for it to be dangerous. Another issue I've seen pop up is the amount of spaghetti you see when someone said "Screw the tests can do it after". You could or couldn't do it after, cos sometimes things are so coupled it's impossible to test in a meaningful way. This varies between developers of course, more junior people will be coupling things more. One approach that has worked for me whenever I'm not quite sure how I am going to implement something is something like this. - First, prototype your feature, go in and go mad, write 0 tests and just try and find out how you're going to build it. - Then, stash it all away, wipe your workspace clean and start with tests. I've found this works for me when I'm not quite sure how I'm going to piece something new together.

eesmith 9y ago

Because if you are for a certain approach then it's easier to put all alternatives in the same category, then pick one as the antithesis, show that your approach is better, and conclude that everything which isn't your approach is worse. You'll see that it's mostly TDD people who treat things as either "test first" or "test last", where "test last" occurs after all development. As another example, agile people say there's "agile" and "waterfall", even though there are many software development approaches other than those two.

marcosdumay 9y ago
Or, in other words, those people are shooting for political dominance and don't care about truth. I am quite sure it is an inconscient bias, but it's tiring to keep listening those dishonest arguments everywhere.

PaulKeeble 9y ago

Some approaches aren't very testable and produce either very bad tests or can't be tested at all.

hdi 9y ago

The problem I've seen come out of test after is complete implementations with 0 tests. People will just forget to do it! Especially if working on few different areas of the code at the same time. And it happens often enough for it to be dangerous. Another issue I've seen pop up is the amount of spaghetti you see when someone said "Screw the tests can do it after". You could or couldn't do it after, cos sometimes things are so coupled it's impossible to test in a meaningful way. This varies between developers of course, more junior people will be coupling things more. One approach that has worked for me whenever I'm not quite sure how I am going to implement something is something like this. - First, prototype your feature, go in and go mad, write 0 tests and just try and find out how you're going to build it. - Then, stash it all away, wipe your workspace clean and start with tests. I've found this works for me when I'm not quite sure how I'm going to piece something new together.