4 ms·

I see unit testing (and especially TDD) as a barrier to agile development. If I'm cranking out a prototype to show a customer then I don't want to spend precio

I see unit testing (and especially TDD) as a barrier to agile development. If I'm cranking out a prototype to show a customer then I don't want to spend precious time writing tests for code that stands a good chance of being thrown away at the start of the next iteration. Tests often do need to be written, but the best time to do this seems like an unsolved problem to me.

johnkchow 14y ago
I definitely agree with the statement about prototyping and testing. Testing is another signal of quality, a guarantee if you will, to your stakeholders that your software provided is dependable and trustworthy. That doesn't matter if you have no customers to begin with! I'd also like to throw it out there that testing can be especially helpful when writing code against known problems. Some benefits are: - Since you already know the problem domain, your test writing will be extremely quick and effortless, so the benefit of having that test in the first place far outweighs the time/effort invested in writing them. - In dynamic languages especially, typos are what kills you in this situation. Testing will quickly catch 'em as you program. - Finally, testing will force you to think more about the edge cases, since implementation is a straight-forward process. Thus, you'll spend less time later doing QA and have an overall more polished feature.
agscala 14y ago
Not only is the best time to write tests an unsolved problem, but also the method in which you write tests. I think TDD is a joke, but unit tests are still valuable.
morphyn 14y ago
Maybe you shouldn't write tests for a "prototype" that you're going to "throw away". Tests are (in my opinion) necessary, but TDD is a style of coding and you don't have to use it.
spdy 14y ago
I discovered for my self that the best time to add tests to a project is when you cant overlook everything anymore and you ran into problems when you add one feature on one side and on the other a whole house breaks down. There is no need to write tests for fast moving objects and for this kind of work TDD is a waste of time in my opinion. But for core infrastructure this makes sense. But driving blind all the time is not a good idea on the long run.
roel_v 14y ago
Your argument can only lead to the logical conclusion that you consider agile development to be only for making prototypes, which I assume you don't mean. But if you don't, your objection becomes unsupported. Maybe the problem is in your seemingly equating unit testing with TDD.
- arctangent 14y ago
  Perhaps my choice of words could have been better... swap out "prototype" (a hyperbolic example) in favour of "iteration" in my second paragraph and see if it makes more sense. The central point I am trying to make is that it seems wasteful to spend time writing tests for code that may soon be deleted.
  - psylence519 14y ago
    All code written has a chance to live forever, you owe some tests to the next guy forced to fix your shit.
  - roel_v 14y ago
    OK then, but in an iteration, you don't throw away everything you have and start from scratch. You use unit tests to check that those parts that weren't changed, weren't affected by the parts that were. Unit testing pays off especially in those scenarios.
    - arctangent 14y ago
      I understand this. But writing tests as you go means you can't introduce new functional code at the same pace. Although I think it's an unsolved problem, I lean heavily towards writing tests (and documentation) towards the end of a project.
bryanlarsen 14y ago
In my experience, a prototype is never just a prototype. You crank out a prototype in an hour to demonstrate something. Then somebody says "add this and then we'll show it to the boss.". Your boss says "that's cool, add this and this and this and then we'll demo it to a potential customer". You do so, then play test the demo a few times, uncovering scenarios that need hardening. You demo to the customer, and they ask a few questions meaning that you add a few more features to the prototype for the next demo. Rinse and repeat. After a few successful demos you're given an tight deadline to "finish things", so you have no choice but to polish up the prototype and ship it. The moral: code that was written to be thrown away often isn't. You can still write code quickly, and take shortcuts (such as skipping tests), but recognize that you'll probably be working on that code for a very long time and may regret your decisions later.
- arctangent 14y ago
  This is what I was alluding to when I mentioned that it's not obvious when tests should be written. It simply isn't practical to write them as part of a quick prototype (or any other rapid iteration). But writing them at the end of a project may also be difficult due to the need to move on to something else. The same argument holds for things like documentation...

johnkchow 14y ago

I definitely agree with the statement about prototyping and testing. Testing is another signal of quality, a guarantee if you will, to your stakeholders that your software provided is dependable and trustworthy. That doesn't matter if you have no customers to begin with! I'd also like to throw it out there that testing can be especially helpful when writing code against known problems. Some benefits are: - Since you already know the problem domain, your test writing will be extremely quick and effortless, so the benefit of having that test in the first place far outweighs the time/effort invested in writing them. - In dynamic languages especially, typos are what kills you in this situation. Testing will quickly catch 'em as you program. - Finally, testing will force you to think more about the edge cases, since implementation is a straight-forward process. Thus, you'll spend less time later doing QA and have an overall more polished feature.

agscala 14y ago

Not only is the best time to write tests an unsolved problem, but also the method in which you write tests. I think TDD is a joke, but unit tests are still valuable.

morphyn 14y ago

Maybe you shouldn't write tests for a "prototype" that you're going to "throw away". Tests are (in my opinion) necessary, but TDD is a style of coding and you don't have to use it.

spdy 14y ago

I discovered for my self that the best time to add tests to a project is when you cant overlook everything anymore and you ran into problems when you add one feature on one side and on the other a whole house breaks down. There is no need to write tests for fast moving objects and for this kind of work TDD is a waste of time in my opinion. But for core infrastructure this makes sense. But driving blind all the time is not a good idea on the long run.

roel_v 14y ago

Your argument can only lead to the logical conclusion that you consider agile development to be only for making prototypes, which I assume you don't mean. But if you don't, your objection becomes unsupported. Maybe the problem is in your seemingly equating unit testing with TDD.

arctangent 14y ago
Perhaps my choice of words could have been better... swap out "prototype" (a hyperbolic example) in favour of "iteration" in my second paragraph and see if it makes more sense. The central point I am trying to make is that it seems wasteful to spend time writing tests for code that may soon be deleted.
- psylence519 14y ago
  All code written has a chance to live forever, you owe some tests to the next guy forced to fix your shit.
- roel_v 14y ago
  OK then, but in an iteration, you don't throw away everything you have and start from scratch. You use unit tests to check that those parts that weren't changed, weren't affected by the parts that were. Unit testing pays off especially in those scenarios.
  - arctangent 14y ago
    I understand this. But writing tests as you go means you can't introduce new functional code at the same pace. Although I think it's an unsolved problem, I lean heavily towards writing tests (and documentation) towards the end of a project.

bryanlarsen 14y ago

In my experience, a prototype is never just a prototype. You crank out a prototype in an hour to demonstrate something. Then somebody says "add this and then we'll show it to the boss.". Your boss says "that's cool, add this and this and this and then we'll demo it to a potential customer". You do so, then play test the demo a few times, uncovering scenarios that need hardening. You demo to the customer, and they ask a few questions meaning that you add a few more features to the prototype for the next demo. Rinse and repeat. After a few successful demos you're given an tight deadline to "finish things", so you have no choice but to polish up the prototype and ship it. The moral: code that was written to be thrown away often isn't. You can still write code quickly, and take shortcuts (such as skipping tests), but recognize that you'll probably be working on that code for a very long time and may regret your decisions later.

arctangent 14y ago
This is what I was alluding to when I mentioned that it's not obvious when tests should be written. It simply isn't practical to write them as part of a quick prototype (or any other rapid iteration). But writing them at the end of a project may also be difficult due to the need to move on to something else. The same argument holds for things like documentation...