Live data from Hacker News

TDD your API

blog.balancedpayments.com

11–20 of 51 posts

Re: TDD your API

#11

The article is very interesting/good, but I do want to mention one issue I have with it: “To say that there’s a large amount of literature on the benefits of this approach would be an understatement.” I've brought this up before, but “literature” carries the connotation of “scientific literature”, and I actually haven't heard of many rigorous, well-constructed scientific experiments that have produced conclusive scie…

Just try it for a while. If it suits you, then keep it in your bag of tools. If you wait for scientific researches to tell you what to do to get better, you will miss on a lot of learning opportunities. - My two cents

Re: TDD your API

#12
post #11

The article is very interesting/good, but I do want to mention one issue I have with it: “To say that there’s a large amount of literature on the benefits of this approach would be an understatement.” I've brought this up before, but “literature” carries the connotation of “scientific literature”, and I actually haven't heard of many rigorous, well-constructed scientific experiments that have produced conclusive scie…

Just try it for a while. If it suits you, then keep it in your bag of tools. If you wait for scientific researches to tell you what to do to get better, you will miss on a lot of learning opportunities. - My two cents

Engineering & anecdotes usually preclude science.

We created some nice catapults before we "understood" gravity. Even now we don't fully understand existence.

Re: TDD your API

#13
If you think about it, tests themselves are really client code for your class interfaces. So TDDing an API is just carrying that metaphor over to services.

Re: TDD your API

#14
post #2

I had a similar goal, and built a simple shell script[1] that would enable its user to write tests as curl requests. [1]: http://mattneary.com/Quizzical/

This looks interesting! Might be worth taking a look at the library we have built to validate the HTTP messages using `curl-trace-parser` (https://github.com/apiaryio/gavel)

Re: TDD your API

#15
What I really like about the author's approach is that it really answers the first question: "How can we validate that our API is working as intended?"

Writing your tests from the client's perspective actually gives you that certainty. TDD is a powerful tool, but in my experience its evangelists get into overly academic debates about exactly what a "unit" is and how strictly you should adhere to the red-green-refactor steps.

For a really thoughtful and in-depth approach to API TDD I recommend Growing Object-Oriented Software, Guided by Tests by Steve Freeman (http://www.amazon.com/Growing-Object-Oriented-Software-Guide...).

Re: TDD your API

#16
This is kinda neat for being able to show some API workflows (like the PATCH update of a document and then GET request to retrieve it), but if you are more interested / content with one-by-one testing of resources, you can use the API Blueprint project (http://apiblueprint.org) to document your API, and then use Dredd (https://github.com/apiaryio/dredd) to test a running version of your API. You can then tie in with their nice visualization tools or upload to apiary.io and take care of your customer-facing docs while you're at it.

Re: TDD your API

#18

The article is very interesting/good, but I do want to mention one issue I have with it: “To say that there’s a large amount of literature on the benefits of this approach would be an understatement.” I've brought this up before, but “literature” carries the connotation of “scientific literature”, and I actually haven't heard of many rigorous, well-constructed scientific experiments that have produced conclusive scie…

The interesting thing to me about TDD is it almost feels like science: make a test, specifically a test of your assumptions (you assume the test will fail and you assume that the code you will create will fix it), test it, then modify from there.

Re: TDD your API

#19

If you think about it, tests themselves are really client code for your class interfaces. So TDDing an API is just carrying that metaphor over to services.

> TDDing an API...

Yes and no. Depends how you "write" those tests. In this case, where you describe the scenarios, it is indeed true. However you can take a different approach – without writing explicit tests (and thus the client code). Rather you just describe your API in a sort of contract and then, as you iterate, you verify the implementation is living up to this contract...

Re: TDD your API

#20
post #16

This is kinda neat for being able to show some API workflows (like the PATCH update of a document and then GET request to retrieve it), but if you are more interested / content with one-by-one testing of resources, you can use the API Blueprint project ( http://apiblueprint.org ) to document your API, and then use Dredd ( https://github.com/apiaryio/dredd ) to test a running version of your API. You can then tie in w…

We explicitly looked at Apiary during this process, but it's lack of hypermedia support was a deal breaker, as you mention.
Post reply on HN