4 ms·

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

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.
  - davidjnelson 10y ago
    Exactly! And to the gp comment, how do you quantify "good api" until someone has used it? And even when someone ends up using it, how will they tell you if they find it easy or hard to use? Also, once it starts getting heavily used, won't that make it much riskier and harder to sell to management to refactor it if you get feedback that it is hard to use? Unit, integration, and functional tests all help here, but let's say your abstraction has adoption at 100 api consumer call sites. There's a lot that could go wrong. Now, if you are the only person using the api for a long time, that's another way to determine if it's a "good api", because you'll use it to build things. Refactoring it is still a tough sell to management in that case though. Not impossible, but tough.

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.
- davidjnelson 10y ago
  Exactly! And to the gp comment, how do you quantify "good api" until someone has used it? And even when someone ends up using it, how will they tell you if they find it easy or hard to use? Also, once it starts getting heavily used, won't that make it much riskier and harder to sell to management to refactor it if you get feedback that it is hard to use? Unit, integration, and functional tests all help here, but let's say your abstraction has adoption at 100 api consumer call sites. There's a lot that could go wrong. Now, if you are the only person using the api for a long time, that's another way to determine if it's a "good api", because you'll use it to build things. Refactoring it is still a tough sell to management in that case though. Not impossible, but tough.