5 ms·

Good API design is part of why I try to follow TDD. I'm not dogmatic about it, but I've noticed that when I do follow it, I usually have a better understanding

Good API design is part of why I try to follow TDD. I'm not dogmatic about it, but I've noticed that when I do follow it, I usually have a better understanding of how I'll use my code by the time I'm done implementing it. Usually because, in the process of testing my code, I'm getting to 'use' it before I've even written it.

taeric 10y ago
This resonates with me. But, I have found that it is often more important to do several to "throw away" than it is to TDD the first. That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the viability of iteration 1 of a program. Instead, it is by iteration 3 that things have a chance. And, it seems, any process is likely to succeed then.
- crdoconnor 10y ago
  BDD allows you to "think through" the consequences of your user stories and potentially discard or amend bad stories before they end up getting implemented and causing problems.
  - taeric 10y ago
    Again, this resonates well. However, I have had many cases where I did not really see what made a story bad until I had almost succeeded in getting it implemented. In the end, I always want a way to make iteration 1 work. For it to be the only time I have to write something. However, experience is having done many many first iterations.
- TillE 10y ago
  It's completely normal to do a throwaway prototype when exploring a new space. There's not many alternatives to that. But when you do have a fairly good understanding of what's going on (and you're unlikely to make major incorrect assumptions), TDD is a big help in designing APIs.
- st3v3r 10y ago
  I took a class on 3D modeling the other week, and the instructor was teaching the "sculpt" method. Instead of getting a bunch of measurements, and building shapes with those exact measurements, you would start with a big ol block, and push and pull the vertices and loops until you have something that looks like what you want. But a huge part of that technique is to throw work away. You do some work, get stuck, and then start over. Sounds wasteful, but by doing so, when you start the next time, you have a much better idea of what you need, and so you're able to go faster the next time. The lesson was designed so that you would have to do this a couple times.
dozzie 10y ago
Following TDD only gives you testable library, not one with good API. Good requires something different. To have a good interface you want to think how would you use it, and only writing it after this step. Probably stopping along the way and stepping backward when problems arise.
- davidjnelson 10y ago
  I'd agree that it doesn't guarantee a good api in all cases. But if you do red green refactor tdd, _you_ are the user of the api from the beginning, so you get to experience what your api consumers will be experiencing. This allows you to think how you and others will use it. Maybe you meant "write unit tests after" instead of "red green refactor tdd" doesn't help with the design of a good api? For me, the benefit of unit testing is in a good design more than the reduced refactoring risk or production bug risk, although those are both beneficial for sure. Now, getting management to invest in tdd is another story :-p
  - dozzie 10y ago
    > Maybe you meant "write unit tests after" instead of "red green refactor tdd" doesn't help with the design of a good api? No. My point was, if you want good API, aim specifically for that, not for some semi-related proxy like tests. And with good interface you may suddenly find out that you actually don't need most of the tests. Tests are heavily overrated when it comes to anything but what they were designed for (i.e. preventing regressions).
    - icebraining 10y ago
      But when you're writing tests for an API that doesn't exist yet, isn't aiming for a good API almost inevitable? I mean, if you're inventing an API from scratch from the user perspective, you're almost bound to aim for something that makes sense, even if turns out to be hard to implement. At least the way I write these tests, and I find it hard to think of another way, is to essentially write the usage examples of the documentation, except they're actually runnable.

taeric 10y ago

This resonates with me. But, I have found that it is often more important to do several to "throw away" than it is to TDD the first. That is, I have yet to find a process TDD/BDD/Whatever, that can truly up the viability of iteration 1 of a program. Instead, it is by iteration 3 that things have a chance. And, it seems, any process is likely to succeed then.

crdoconnor 10y ago
BDD allows you to "think through" the consequences of your user stories and potentially discard or amend bad stories before they end up getting implemented and causing problems.
- taeric 10y ago
  Again, this resonates well. However, I have had many cases where I did not really see what made a story bad until I had almost succeeded in getting it implemented. In the end, I always want a way to make iteration 1 work. For it to be the only time I have to write something. However, experience is having done many many first iterations.
TillE 10y ago
It's completely normal to do a throwaway prototype when exploring a new space. There's not many alternatives to that. But when you do have a fairly good understanding of what's going on (and you're unlikely to make major incorrect assumptions), TDD is a big help in designing APIs.
st3v3r 10y ago
I took a class on 3D modeling the other week, and the instructor was teaching the "sculpt" method. Instead of getting a bunch of measurements, and building shapes with those exact measurements, you would start with a big ol block, and push and pull the vertices and loops until you have something that looks like what you want. But a huge part of that technique is to throw work away. You do some work, get stuck, and then start over. Sounds wasteful, but by doing so, when you start the next time, you have a much better idea of what you need, and so you're able to go faster the next time. The lesson was designed so that you would have to do this a couple times.

dozzie 10y ago

Following TDD only gives you testable library, not one with good API. Good requires something different. To have a good interface you want to think how would you use it, and only writing it after this step. Probably stopping along the way and stepping backward when problems arise.

davidjnelson 10y ago
I'd agree that it doesn't guarantee a good api in all cases. But if you do red green refactor tdd, _you_ are the user of the api from the beginning, so you get to experience what your api consumers will be experiencing. This allows you to think how you and others will use it. Maybe you meant "write unit tests after" instead of "red green refactor tdd" doesn't help with the design of a good api? For me, the benefit of unit testing is in a good design more than the reduced refactoring risk or production bug risk, although those are both beneficial for sure. Now, getting management to invest in tdd is another story :-p
- dozzie 10y ago
  > Maybe you meant "write unit tests after" instead of "red green refactor tdd" doesn't help with the design of a good api? No. My point was, if you want good API, aim specifically for that, not for some semi-related proxy like tests. And with good interface you may suddenly find out that you actually don't need most of the tests. Tests are heavily overrated when it comes to anything but what they were designed for (i.e. preventing regressions).
  - icebraining 10y ago
    But when you're writing tests for an API that doesn't exist yet, isn't aiming for a good API almost inevitable? I mean, if you're inventing an API from scratch from the user perspective, you're almost bound to aim for something that makes sense, even if turns out to be hard to implement. At least the way I write these tests, and I find it hard to think of another way, is to essentially write the usage examples of the documentation, except they're actually runnable.