5 ms·

How I reliably enter the Zone: TDD

19 points by akkartik 18y ago

ardit33 18y ago
There is another way better way. Program to interfaces. Or write out all the methods you need, have empty bodies, and implement them one by one. From the lower level/helpers, to the higher level ones. If any method becomes too large, or if there is a lot of redundancy, break it in smaller units. I think TDD hampers design, as it places a penalty on every time you want to reactor code while you are still implementing it and it keeps you vested on current code, which is against the "keep it simple, and easy to change" principle. In languages like java, it may force you to break encapsulation and good design, just to have your code tested. (how many times have you see this comment: "don't use this, just for testing purposes") in side of methods. If you must do testing, a functional level testing is much better. Where you test only the higher level methods that have are acting on the functionality, but don't care about the lower level/helper methods. Take the holistic approach, and don't sweat the details. If you do a good job on breaking the implementation in small/reasonable sized methods, then it is easy to spot errors when you are developing. Try the best to avoid methods with side effects (modifying shared resources), and keep the methods dumb: input in, input out, no side effects.. Just test the one method that is being called for that particular functionality, and if everything is working well, your overall test should come out as positive. What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types.
- ratsbane 18y ago
  That is consistent with what I've been thinking, too. Also, I have the impression that TDD is more relevant to non-web development. Most of my work at the moment is in mod_perl and the i/o is all though web pages. How does TDD work with web development? Can anyone recommend any reading, video, etc?
- jcapote 18y ago
  Great post, I was feeling lonely in the small-clean-code-works-just-fine-without-tests camp
- kristiandupont 18y ago
  While I can't prove it, my intuition tells me that when I do TDD, my designs are much more flexible and my code is much more reliable. Stuff that I would have buried in one class is often split into smaller classes. This gives some overhead, yes, but the tests are well worth the effort. >"If you must do testing..." Are you suggesting that tests are bad in general?
  - ardit33 18y ago
    no. Testing has it's place, in important functionality, high level features, or if you are dealing with 3rd party, outsourcing companies, and integrating their code (make sure their stuff works as specified). TDD by definition is build the test first, and then develop, which is implies, test everything. Most of the code people write is not really test worthy.
    - aaronblohowiak 18y ago
      "TDD by definition is build the test first, and then develop, which is implies, test everything." That is errant. You can create high-level tests for new functionality, and then implement the myriad of implementation details to fulfill that test. Until all of our languages and libraries have 100% test coverage, you must decide to draw the line short somewhere. Disclaimer: I am not a TDD aficionado, and we don't practice it at the dayjob.
- abdulhaq 18y ago
  > "you must cover 90% of your code with unit tests" No, TDD doesn't mean that. TDD is where you write the tests _first_. This bestows numerous advantages that post-facto tests don't: 1) You think about the API as required by the person using the interface that you are coding up. 2) - and this is the killer - you are forced to create repeatable test data and fixtures (e.g. in memory sql databases a la sqlite). As the functionality and number of services builds up, you create, whether you like it or not, a large suite of easily instantiated, complex mock services that allow you to build truly automated and repeatable high level tests. 3) And you can then safely refactor much more reliably and confidently when features and ideas have changed. I agree that writing tests after the fact is a waste of time. TDD saves time (and hair!).
  - gaius 18y ago
    TDD is a brute-force method for evading the need to understand side-effects. I consider situations in which TDD applies to be warning signs, not opportunities.
    - deleted 18y ago
      [deleted]
    - eru 18y ago
      Side-effects are evil [1] and it's good that TDD encourages you to minimize side-effects. [1] That's one reason why functional programming raises productivity.
- bryanl 18y ago
  You can TDD at the functional level. I don't see what the big deal is.
- akkartik 18y ago
  "What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types." Amen, brother. The only experience I have with TDD is for my own projects, working solo. Nobody will truly understand it if they don't come to it of their own choice.
Tichy 18y ago
tdd = test driven design
DanielBMarkham 18y ago
I'm an agile coach, so I'm supposed to support TDD. But I just don't get it. I think you should unit test as you code, sure (for big things), but testing as a design strategy? As a way of "getting into the zone"? I'm glad this guy seems excited about it. I'm trying to collect examples of people who actually use it out of their own choice. I think this is number 4 from the last six months. Nobody wants to be behind the curve -- maybe TDD is the next evolution in programming styles. Or maybe it's just a reaction against heavy-handed, overdone design by architects. Or maybe a little of each. The jury is still out with me.
- akkartik 18y ago
  I'm not sure how well TDD works in the large, but for one man on small projects it's great. It's not substituting for design or anything. It's keeping me from getting stuck in a rut. But it's possible it's not so much TDD as just the process of managing stories. If that helps understand where I'm coming from.
  - DanielBMarkham 18y ago
    From what I can see (and I've read up a bit and worked with some of the big guys in the field) TDD is a "small shop" kind of philosophy. I would think it would work best in teams of 1-4 developers. 4 or over, however, and it seems like it would fall apart. People factor out code in different ways -- for instance, some naturally lean towards functional code while others lean toward imperative code. In modern languages, you can use both. Some folks love interfaces while others won't stand for a public variable. How code "smells" (and I hate that term) looks to me like it can vary a whole lot depending on the programmer. So in larger teams, you can't have 10 different versions of code re-factoring. You have to expect some consistency. There is a place for group decisions. Some team-level thinking ahead makes sense. But on a 1 or 2 person team? That looks like a completely different animal. What we're finding, however (as consultants), is that companies are getting sold on lightweight technologies that work great at the small team level and then don't work so hot with fifty thousand developers. It's complex. Thanks for the feedback. HappyTDDCoderCount++
DenisM 18y ago
FWIW a book recommendation from articles comments: http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530 http://www.amazon.com/Test-Driven-Development-Addison-Wesley...

19 points by akkartik 18y ago

There is another way better way. Program to interfaces. Or write out all the methods you need, have empty bodies, and implement them one by one. From the lower level/helpers, to the higher level ones. If any method becomes too large, or if there is a lot of redundancy, break it in smaller units. I think TDD hampers design, as it places a penalty on every time you want to reactor code while you are still implementing it and it keeps you vested on current code, which is against the "keep it simple, and easy to change" principle. In languages like java, it may force you to break encapsulation and good design, just to have your code tested. (how many times have you see this comment: "don't use this, just for testing purposes") in side of methods. If you must do testing, a functional level testing is much better. Where you test only the higher level methods that have are acting on the functionality, but don't care about the lower level/helper methods. Take the holistic approach, and don't sweat the details. If you do a good job on breaking the implementation in small/reasonable sized methods, then it is easy to spot errors when you are developing. Try the best to avoid methods with side effects (modifying shared resources), and keep the methods dumb: input in, input out, no side effects.. Just test the one method that is being called for that particular functionality, and if everything is working well, your overall test should come out as positive. What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types.

ratsbane 18y ago
That is consistent with what I've been thinking, too. Also, I have the impression that TDD is more relevant to non-web development. Most of my work at the moment is in mod_perl and the i/o is all though web pages. How does TDD work with web development? Can anyone recommend any reading, video, etc?
jcapote 18y ago
Great post, I was feeling lonely in the small-clean-code-works-just-fine-without-tests camp
kristiandupont 18y ago
While I can't prove it, my intuition tells me that when I do TDD, my designs are much more flexible and my code is much more reliable. Stuff that I would have buried in one class is often split into smaller classes. This gives some overhead, yes, but the tests are well worth the effort. >"If you must do testing..." Are you suggesting that tests are bad in general?
- ardit33 18y ago
  no. Testing has it's place, in important functionality, high level features, or if you are dealing with 3rd party, outsourcing companies, and integrating their code (make sure their stuff works as specified). TDD by definition is build the test first, and then develop, which is implies, test everything. Most of the code people write is not really test worthy.
  - aaronblohowiak 18y ago
    "TDD by definition is build the test first, and then develop, which is implies, test everything." That is errant. You can create high-level tests for new functionality, and then implement the myriad of implementation details to fulfill that test. Until all of our languages and libraries have 100% test coverage, you must decide to draw the line short somewhere. Disclaimer: I am not a TDD aficionado, and we don't practice it at the dayjob.
abdulhaq 18y ago
> "you must cover 90% of your code with unit tests" No, TDD doesn't mean that. TDD is where you write the tests _first_. This bestows numerous advantages that post-facto tests don't: 1) You think about the API as required by the person using the interface that you are coding up. 2) - and this is the killer - you are forced to create repeatable test data and fixtures (e.g. in memory sql databases a la sqlite). As the functionality and number of services builds up, you create, whether you like it or not, a large suite of easily instantiated, complex mock services that allow you to build truly automated and repeatable high level tests. 3) And you can then safely refactor much more reliably and confidently when features and ideas have changed. I agree that writing tests after the fact is a waste of time. TDD saves time (and hair!).
- gaius 18y ago
  TDD is a brute-force method for evading the need to understand side-effects. I consider situations in which TDD applies to be warning signs, not opportunities.
  - deleted 18y ago
    [deleted]
  - eru 18y ago
    Side-effects are evil [1] and it's good that TDD encourages you to minimize side-effects. [1] That's one reason why functional programming raises productivity.
bryanl 18y ago
You can TDD at the functional level. I don't see what the big deal is.
akkartik 18y ago
"What I really hate is mandatory: "you must cover 90% of your code with unit tests" type of orders by CTO/VP engineering types." Amen, brother. The only experience I have with TDD is for my own projects, working solo. Nobody will truly understand it if they don't come to it of their own choice.

Tichy 18y ago

tdd = test driven design

DanielBMarkham 18y ago

I'm an agile coach, so I'm supposed to support TDD. But I just don't get it. I think you should unit test as you code, sure (for big things), but testing as a design strategy? As a way of "getting into the zone"? I'm glad this guy seems excited about it. I'm trying to collect examples of people who actually use it out of their own choice. I think this is number 4 from the last six months. Nobody wants to be behind the curve -- maybe TDD is the next evolution in programming styles. Or maybe it's just a reaction against heavy-handed, overdone design by architects. Or maybe a little of each. The jury is still out with me.

akkartik 18y ago
I'm not sure how well TDD works in the large, but for one man on small projects it's great. It's not substituting for design or anything. It's keeping me from getting stuck in a rut. But it's possible it's not so much TDD as just the process of managing stories. If that helps understand where I'm coming from.
- DanielBMarkham 18y ago
  From what I can see (and I've read up a bit and worked with some of the big guys in the field) TDD is a "small shop" kind of philosophy. I would think it would work best in teams of 1-4 developers. 4 or over, however, and it seems like it would fall apart. People factor out code in different ways -- for instance, some naturally lean towards functional code while others lean toward imperative code. In modern languages, you can use both. Some folks love interfaces while others won't stand for a public variable. How code "smells" (and I hate that term) looks to me like it can vary a whole lot depending on the programmer. So in larger teams, you can't have 10 different versions of code re-factoring. You have to expect some consistency. There is a place for group decisions. Some team-level thinking ahead makes sense. But on a 1 or 2 person team? That looks like a completely different animal. What we're finding, however (as consultants), is that companies are getting sold on lightweight technologies that work great at the small team level and then don't work so hot with fifty thousand developers. It's complex. Thanks for the feedback. HappyTDDCoderCount++

DenisM 18y ago

FWIW a book recommendation from articles comments: http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530 http://www.amazon.com/Test-Driven-Development-Addison-Wesley...