5 ms·

> Writing tests before code works pretty well in some situations. Test Driven Development, as handed down to us mortals by Agile Testing Experts and other assor

by Volpe 15y ago

> Writing tests before code works pretty well in some situations. Test Driven Development, as handed down to us mortals by Agile Testing Experts and other assorted shills, is hocus. What? So it works in some situations, but not all. Thus hocus? I'm no 'Agile Testing Expert', but I have worked for the last 2-3 years doing TDD exclusively (as in ALWAYS writing tests first). It isn't hocus. It is effective. I can understand it doesn't suit all problems, and can potentially be a hinderance sometimes, but that is the same for ANY methodology/practice. I don't quite understand your hostility towards it. What do you mean by 'developer driven testing'?

tomjen3 15y ago
The hocus is not that you can use TDD, if, in your professional judgment, you believe that to be the best solution to the problem. The hocus is that you must use it, because some guru said so.
berntb 15y ago
Excuse me for interrupting the budding flame war, but I have a question regarding the subject, which you seem qualified to answer? :-) My experience is the same as (what I believe is) the usual criticism of tests-first. I often need to rethink the API to my functions/methods, sometimes more than once. This goes for both external and internal APIs, so it doesn't help with detailed interface specifications between modules. Test-first is a problem, since it needs a fixed interface before I'm ready to lock down the interface. I tend to instead write inside-out; a few pages of code and then write tests for that code. That model isn't really kosher/halal/etc, according to TDD?
- tychof 15y ago
  One benefit to TDD is that you become a user for your API much more quickly, and so your API doesn't need to change as much. TDD suggests 3 steps: 1. Write one test 2. Write the minimal code to make it pass 3. Refactor the code you've got. Try not to think of tests as immutable. You can throw away tests when they don't provide value. Finally, make sure you're using an IDE with refactoring support. That helps immensely when you make an API change which will affect your tests.
  - berntb 15y ago
    OK, thanks to you and zumda. Interesting TDD argument. I'll buy a book or something and try again when my present hobby project is done and I have time for experimenting. (IDE refactoring needs a stricter language than I prefer. Also, without an IDE and using my old eyes I have 2 A4 of code + 1 A4 of bash on a 24" monitor...)
    - zts 15y ago
      If you're looking for book suggestions, I'd recommend "Growing Object-Oriented Software, Guided By Tests" by Steve Freeman and Nat Pryce. It's pretty pragmatic, and the treatment of the subject is pretty thought-provoking (at least, I thought so when I read it). The examples are all Java, but the accompanying website (http://www.growing-object-oriented-software.com/ http://www.growing-object-oriented-software.com/) has links to reimplementations in several other languages.
- zumda 15y ago
  According to TDD writing inside-out is one of the points it tries to combat. The point of using TDD to write interfaces is that you first write the code you wish you had, and then implement it. The other way around you could end up with code that is optimized for the code inside the module, and not optimized for using it. Of course now you have to rewrite your tests and your code when changing an API, but at least you know that no other part of your application got broken by the new API. I personally like the TDD approach to write interfaces, since then I won't take shortcuts just because it is easier to do in the specific module that I'm programming/extending. It will actually produce code that can be used easily from the outside and removes a lot of dependencies in the process.
peteretep 15y ago
> I can understand it doesn't suit all problems, and can potentially be a hinderance sometimes Then why do it exclusively? Testing is about helping developers, and recognizing that automated testing is about benefit to developers, rather than cargo-culting a workflow and decreeing that one size fits all. Writing tests first as a tool to be deployed where it works is "Developer Driven Testing" - focussing on making the developer more productive by choosing the right tool for the job. Generalizing a bunch of testing rules and saying This Is The One True Way Even When It Isn't (I mean seriously, you continued to use it when it was a hindrance?!) - that's not right.
- Volpe 15y ago
  Primarily I do web development, with python and ruby, TDDing is VERY well supported, and thus has allowed me to do it exclusively. But I can imagine there are systems out there that are difficult to TDD, web apps are not among them though. Sounds like you are interpreting TDD in a rather extreme way. If you haven't found it useful, then fine don't use it. But that doesn't mean it is universally bad, and thus doesn't deserve the "It's all hocus and you are a stupid zealot if you do it"

by Volpe 15y ago

tomjen3 15y ago

The hocus is not that you can use TDD, if, in your professional judgment, you believe that to be the best solution to the problem. The hocus is that you must use it, because some guru said so.

berntb 15y ago

Excuse me for interrupting the budding flame war, but I have a question regarding the subject, which you seem qualified to answer? :-) My experience is the same as (what I believe is) the usual criticism of tests-first. I often need to rethink the API to my functions/methods, sometimes more than once. This goes for both external and internal APIs, so it doesn't help with detailed interface specifications between modules. Test-first is a problem, since it needs a fixed interface before I'm ready to lock down the interface. I tend to instead write inside-out; a few pages of code and then write tests for that code. That model isn't really kosher/halal/etc, according to TDD?

tychof 15y ago
One benefit to TDD is that you become a user for your API much more quickly, and so your API doesn't need to change as much. TDD suggests 3 steps: 1. Write one test 2. Write the minimal code to make it pass 3. Refactor the code you've got. Try not to think of tests as immutable. You can throw away tests when they don't provide value. Finally, make sure you're using an IDE with refactoring support. That helps immensely when you make an API change which will affect your tests.
- berntb 15y ago
  OK, thanks to you and zumda. Interesting TDD argument. I'll buy a book or something and try again when my present hobby project is done and I have time for experimenting. (IDE refactoring needs a stricter language than I prefer. Also, without an IDE and using my old eyes I have 2 A4 of code + 1 A4 of bash on a 24" monitor...)
  - zts 15y ago
    If you're looking for book suggestions, I'd recommend "Growing Object-Oriented Software, Guided By Tests" by Steve Freeman and Nat Pryce. It's pretty pragmatic, and the treatment of the subject is pretty thought-provoking (at least, I thought so when I read it). The examples are all Java, but the accompanying website (http://www.growing-object-oriented-software.com/ http://www.growing-object-oriented-software.com/) has links to reimplementations in several other languages.
zumda 15y ago
According to TDD writing inside-out is one of the points it tries to combat. The point of using TDD to write interfaces is that you first write the code you wish you had, and then implement it. The other way around you could end up with code that is optimized for the code inside the module, and not optimized for using it. Of course now you have to rewrite your tests and your code when changing an API, but at least you know that no other part of your application got broken by the new API. I personally like the TDD approach to write interfaces, since then I won't take shortcuts just because it is easier to do in the specific module that I'm programming/extending. It will actually produce code that can be used easily from the outside and removes a lot of dependencies in the process.

peteretep 15y ago

> I can understand it doesn't suit all problems, and can potentially be a hinderance sometimes Then why do it exclusively? Testing is about helping developers, and recognizing that automated testing is about benefit to developers, rather than cargo-culting a workflow and decreeing that one size fits all. Writing tests first as a tool to be deployed where it works is "Developer Driven Testing" - focussing on making the developer more productive by choosing the right tool for the job. Generalizing a bunch of testing rules and saying This Is The One True Way Even When It Isn't (I mean seriously, you continued to use it when it was a hindrance?!) - that's not right.

Volpe 15y ago
Primarily I do web development, with python and ruby, TDDing is VERY well supported, and thus has allowed me to do it exclusively. But I can imagine there are systems out there that are difficult to TDD, web apps are not among them though. Sounds like you are interpreting TDD in a rather extreme way. If you haven't found it useful, then fine don't use it. But that doesn't mean it is universally bad, and thus doesn't deserve the "It's all hocus and you are a stupid zealot if you do it"