4 ms·

Review: “Test-Driven Development” by Kent Beck [The creator of JUnit]

20 points by monksy 14y ago

k_bx 14y ago
copy of my comment: I am python developer. I also ask myself these questions, and on current project I use TDD heavily (but still far from 100%). One thing it totally gives me is ability to let other devs in team without need of tons of collaboration to implement some functionality, and then for me being able to refactor it as much as I want, but not being blamed for errors. Since it's their job to put as much tests as would cover all functionality, and it's my job to only write tests for my new code, and fix (or remove) old tests. I think this blame-less in dynamic languages like python is real diamond :) Also, one question I ask myself is "unit-testing vs type theory". And can unit-testing in dynamic language be an instrument that would make dynamic type-checking to be a good thing even in serious production. It's also a big question, and there's a lot to think on it.
adrianhoward 14y ago
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...
gaius 14y ago
Everything you need to know about TDD: http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...
powerslave12r 14y ago
Question: I recently got these two books - Test Driven: TDD and Acceptance TDD for Java Developers - Agile Java™: Crafting Code with Test-Driven Development I'm an experienced programmer but new to Java and TDD. Do I need the book that is reviewed here? I considered it back when I was buying the other two books.
- monksy 14y ago
  Author of the review here: Yes, this book will be for you. I haven't read those other books, but this book is very light on the actual java usage. As long as you can create a class, and create a test class in java. You should be good. Follow along with the examples, and do all of them. I'm assuming that you'll be using an IDE.
- adrianhoward 14y ago
  I'd definitely consider it. It's by the man who invested the concept of TDD and the xUnit framework after all :-) My experience is that people tend to split into two camps. One group prefers Kent's book - which is kind of like the K&R of TDD. It's thin and very to the point, but needs a bit of work from the reader to get the best out of it. The examples are deliberately simple to express the concepts clearly. The other prefers David Astel 's "Test-driven Development: A Practical Guide". It's a bit more grounded in real world examples, which some folk seem to find an easier way to get a grip on the concepts. Another thing to bear in mind that they both talk about "old" versions of JUnit - before they rebuilt it based on attributes - so you're probably going to want to look at something that covers the latest JUnit or TestNG or something (I'm not a Java hacker by trade - so can't really comment on what the best testing environment is there these days).
ollysb 14y ago
I read a few TDD books before this one but this was the book that really got me to understand the difference between simply test-first and test-driven development. The worked example in the first section of the book really illustrates how to using test-driven to evolve the design of the code that you're writing. Previously I'd approached TDD as figuring out how I want the code to work in my head first and then writing a test that would then let me write that code. Having read this book I now write the tests as a description of how I want the code to behave without first giving consideration to how the implementation will work.
ludicast 14y ago
I loved his TDD series on pragprog.

20 points by monksy 14y ago

k_bx 14y ago

copy of my comment: I am python developer. I also ask myself these questions, and on current project I use TDD heavily (but still far from 100%). One thing it totally gives me is ability to let other devs in team without need of tons of collaboration to implement some functionality, and then for me being able to refactor it as much as I want, but not being blamed for errors. Since it's their job to put as much tests as would cover all functionality, and it's my job to only write tests for my new code, and fix (or remove) old tests. I think this blame-less in dynamic languages like python is real diamond :) Also, one question I ask myself is "unit-testing vs type theory". And can unit-testing in dynamic language be an instrument that would make dynamic type-checking to be a good thing even in serious production. It's also a big question, and there's a lot to think on it.

adrianhoward 14y ago

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...

gaius 14y ago

Everything you need to know about TDD: http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku-solvers.html http://ravimohan.blogspot.co.uk/2007/04/learning-from-sudoku...

powerslave12r 14y ago

Question: I recently got these two books - Test Driven: TDD and Acceptance TDD for Java Developers - Agile Java™: Crafting Code with Test-Driven Development I'm an experienced programmer but new to Java and TDD. Do I need the book that is reviewed here? I considered it back when I was buying the other two books.

monksy 14y ago
Author of the review here: Yes, this book will be for you. I haven't read those other books, but this book is very light on the actual java usage. As long as you can create a class, and create a test class in java. You should be good. Follow along with the examples, and do all of them. I'm assuming that you'll be using an IDE.
adrianhoward 14y ago
I'd definitely consider it. It's by the man who invested the concept of TDD and the xUnit framework after all :-) My experience is that people tend to split into two camps. One group prefers Kent's book - which is kind of like the K&R of TDD. It's thin and very to the point, but needs a bit of work from the reader to get the best out of it. The examples are deliberately simple to express the concepts clearly. The other prefers David Astel 's "Test-driven Development: A Practical Guide". It's a bit more grounded in real world examples, which some folk seem to find an easier way to get a grip on the concepts. Another thing to bear in mind that they both talk about "old" versions of JUnit - before they rebuilt it based on attributes - so you're probably going to want to look at something that covers the latest JUnit or TestNG or something (I'm not a Java hacker by trade - so can't really comment on what the best testing environment is there these days).

ollysb 14y ago

I read a few TDD books before this one but this was the book that really got me to understand the difference between simply test-first and test-driven development. The worked example in the first section of the book really illustrates how to using test-driven to evolve the design of the code that you're writing. Previously I'd approached TDD as figuring out how I want the code to work in my head first and then writing a test that would then let me write that code. Having read this book I now write the tests as a description of how I want the code to behave without first giving consideration to how the implementation will work.

ludicast 14y ago

I loved his TDD series on pragprog.