4 ms·

I wouldn't call myself a regular practitioner of TDD but I can tell you that it's incredibly valuable in certain circumstances. When you're writing code that, f

I wouldn't call myself a regular practitioner of TDD but I can tell you that it's incredibly valuable in certain circumstances. When you're writing code that, for example, must be mathematically accurate, writing unit tests can be very useful just so you can assure yourself that you wrote the calculations down correctly. They're also very useful for other "pure" operations. A factory should always produce an object with such and such properties. A user input validation method should always fail given some classification of invalid input, etc. Hardcore TDD is definitely not The Way for me but it's very good to use at times. You'd be amazed how much it speeds up testing these kinds of processes when you can just watch your list of tests change from pass to fail or vice versa. As with anything, your mileage may vary.

RyanZAG 10y ago
I think you're confusing TDD with unit testing. You can unit test without TDD.
- neurotrace 10y ago
  I'm not. I know you can do TDD without unit testing but it's very rare in my experience. I'm saying that the TDD cycle (write tests, run all and verify failures, write actual code, run all tests hoping to see no failures, refactor as needed until step 4 passes) works best when applied to unit tests. Integration tests, acceptance tests, and other "big" tests don't lend themselves well to that style of programming, in my opinion.
  - ldjb 10y ago
    I think RyanZAG is saying you can do unit testing outside of TDD, not that you can do TDD without unit testing. The fact is that both are true. You don't need TDD to use unit testing — you can implement first and test afterwards. In some cases, this may actually be preferable. However, although TDD isn't a silver bullet solution, it can be very helpful in a lot of cases. Like with a lot of things, the usefulness of TDD depends on the situation at hand, and a good software engineer chooses the right development techniques for the job. Unit testing of some sort, however, is considered good practice regardless of whether you're using TDD or not. (And of course, integration and acceptance testing is a good idea, too.)
- mi100hael 10y ago
  > You'd be amazed how much it speeds up testing these kinds of processes when you can just watch your list of tests change from pass to fail or vice versa. That sounds like a test-first strategy, which I would categorize as TDD. Yes, you can write unit tests without it being TDD, but I'll second the notion that the sorts of situations the parent pointed out benefit from a test driven approach.

RyanZAG 10y ago

I think you're confusing TDD with unit testing. You can unit test without TDD.

neurotrace 10y ago
I'm not. I know you can do TDD without unit testing but it's very rare in my experience. I'm saying that the TDD cycle (write tests, run all and verify failures, write actual code, run all tests hoping to see no failures, refactor as needed until step 4 passes) works best when applied to unit tests. Integration tests, acceptance tests, and other "big" tests don't lend themselves well to that style of programming, in my opinion.
- ldjb 10y ago
  I think RyanZAG is saying you can do unit testing outside of TDD, not that you can do TDD without unit testing. The fact is that both are true. You don't need TDD to use unit testing — you can implement first and test afterwards. In some cases, this may actually be preferable. However, although TDD isn't a silver bullet solution, it can be very helpful in a lot of cases. Like with a lot of things, the usefulness of TDD depends on the situation at hand, and a good software engineer chooses the right development techniques for the job. Unit testing of some sort, however, is considered good practice regardless of whether you're using TDD or not. (And of course, integration and acceptance testing is a good idea, too.)
mi100hael 10y ago
> You'd be amazed how much it speeds up testing these kinds of processes when you can just watch your list of tests change from pass to fail or vice versa. That sounds like a test-first strategy, which I would categorize as TDD. Yes, you can write unit tests without it being TDD, but I'll second the notion that the sorts of situations the parent pointed out benefit from a test driven approach.