4 ms·

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

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