4 ms·

The book is designed for people who are new to unit testing and Test-Driven Development. For anyone in the current software development industry, this is very f

The book is designed for people who are new to unit testing and Test-Driven Development. For anyone in the current software development industry, this is very few people. Sigh. I only wish this were true :-) I encounter a lot of people who say that they do TDD, or understand TDD, but they're often doing something very different from what Beck describes. For example the number of folk who treat TDD as a synonym for unit testing is scary. Far to many folk see the "T" and forget about the "DD".

k_bx 14y ago
> For example the number of folk who treat TDD as a synonym for unit testing is scary. I think the problem is in 2 parts: in TDD term (Test-Driven Design/Development, it's just not that obvious), and in lack of unit-testing at most projects (I see) at all. Was there any statistics on that, by the way?
- adrianhoward 14y ago
  Was there any statistics on that, by the way? Nope. Only my personal experiences of talking to folk and teaching/advocating TDD. I encounter a lot of folk who think just using an xUnit framework == doing TDD. It's depressing. My experiences may be biased since I'm often brought to help out with folk who are having problems. However Googling for things like "TDD is not about testing" shows lots of people having similar experiences :-)
monksy 14y ago
One of the most irritating things about this book that I found with that section was that the process was: 1. Write a test for function(5) == 20. 2. Make function { return 20 } Then it goes to the next input: 1. Write a test for function(4) == 16 2. Make function { return parm * 4 } This gets annoying when you know the problem is to make a function multiply by 4.
- ollysb 14y ago
  I seem to recall that he talks about step size. The technique you're referring to is called triangulation, where you use sets of inputs/outputs to progressively generalize the implementation. It's good to know how to work at this small "step size" for those occasions that you're working on something complex or simply don't have much of an idea about how to implement something. If you're coding a familiar problem then you can increase the "step size" and not take all the baby steps i.e. for the example you mention you would probably just use a single input/output set and code the final implementation immediately. The key is understanding that you can start with a larger "step size" and then backtrack and increase the granularity of your steps if you find things are getting a bit hairy...

k_bx 14y ago

> For example the number of folk who treat TDD as a synonym for unit testing is scary. I think the problem is in 2 parts: in TDD term (Test-Driven Design/Development, it's just not that obvious), and in lack of unit-testing at most projects (I see) at all. Was there any statistics on that, by the way?

adrianhoward 14y ago
Was there any statistics on that, by the way? Nope. Only my personal experiences of talking to folk and teaching/advocating TDD. I encounter a lot of folk who think just using an xUnit framework == doing TDD. It's depressing. My experiences may be biased since I'm often brought to help out with folk who are having problems. However Googling for things like "TDD is not about testing" shows lots of people having similar experiences :-)

monksy 14y ago

One of the most irritating things about this book that I found with that section was that the process was: 1. Write a test for function(5) == 20. 2. Make function { return 20 } Then it goes to the next input: 1. Write a test for function(4) == 16 2. Make function { return parm * 4 } This gets annoying when you know the problem is to make a function multiply by 4.

ollysb 14y ago
I seem to recall that he talks about step size. The technique you're referring to is called triangulation, where you use sets of inputs/outputs to progressively generalize the implementation. It's good to know how to work at this small "step size" for those occasions that you're working on something complex or simply don't have much of an idea about how to implement something. If you're coding a familiar problem then you can increase the "step size" and not take all the baby steps i.e. for the example you mention you would probably just use a single input/output set and code the final implementation immediately. The key is understanding that you can start with a larger "step size" and then backtrack and increase the granularity of your steps if you find things are getting a bit hairy...