Live data from Hacker News

TDD your API

blog.balancedpayments.com

1–10 of 51 posts

Re: TDD your API

#3
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 scientific literature that indicates the benefits of TDD. There's certainly a lot of anecdotal posts and writings, but there seems to be relatively little actual “literature” in the most commonly used sense.

Not saying TDD is bad, of course… Just wondering if this is in fact an overstatement rather than an understatement. If we're going to appeal to authority, we should make sure that authority is valid :)

Re: TDD your API

#4
I've used tests similarly when designing APIs, partly to subject myself to my API's UX flaws.

I write mostly functional/integration tests[1]. I try to avoid needing unit tests by making mistakes/errors of that sort impossible by construction (types).

Good post.

[1] https://github.com/bitemyapp/bloodhound/blob/master/tests/te...

Re: TDD your API

#5

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…

> I actually haven't heard of many rigorous, well-constructed scientific experiments that have produced conclusive scientific literature that indicates the benefits of TDD.

I was thinking specifically of things like the http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... when I wrote that sentence, but I guess I also consider books as part of what I'm saying here.

Re: TDD your API

#6
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/

The challenge we had with that approach was being able to reference the response of a previous request.

As a simple example:

1. Create customer

2. Add tokenized card to customer

3. Charge the card

Step 2 requires the HREF/ID of the customer. Step 3 requires the HREF/ID of the card.

Re: TDD your API

#7
I struggle with this all the time. Data driven tests are awesome because you write so little code. But the code is often abstract and the data is long and hard to read.

I have never been a big fan of Cucumber either and I'm not convinced its more readable -- isn't it just more verbose? Interesting point about it being language agnostic though.

I guess I don't have a better solution to contribute. Just wanted to say yeah I have that problem too.

Re: TDD your API

#8

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…

> I actually haven't heard of many rigorous, well-constructed scientific experiments that have produced conclusive scientific literature that indicates the benefits of TDD. I was thinking specifically of things like the http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.... when I wrote that sentence, but I guess I also consider books as part of what I'm saying here.

The whole of the industry suffers from this. I know they are vastly dissimilar as software doesn't have the issues that tangible real-world stuff has, but you'd never see someone proposing a bridge being built on the principals read in some book or a paper that doesn't compare any other theory. I dread the day we have rigorous IT standards as much as I can't wait for it. I've heard it is possible with Ada and lots of concern, money, and talent, but I wonder if we'll ever see that elsewhere. I guess as a whole the tools we rely upon are getting better, but I'm not convinced the methodologies haven't been just more perpetual motion machines.

Re: TDD your API

#9
post #7

I struggle with this all the time. Data driven tests are awesome because you write so little code. But the code is often abstract and the data is long and hard to read. I have never been a big fan of Cucumber either and I'm not convinced its more readable -- isn't it just more verbose? Interesting point about it being language agnostic though. I guess I don't have a better solution to contribute. Just wanted to say y…

I also see Cucumber as a way of gluing specifications with implementation allowing you to regression test specifications.

You can end up with a very domain specific testing "language" (DSTL?) enabling developers and domain experts to start describing a lot of different behavior (specifications) to see if the current implementation supports the behavior.

If current implementation does not support the behavior, then you now have a specification to implement the behavior.

Re: TDD your API

#10
It's really, really nice to see an API with all the validating JSON Schemas publically available[1]. I wish everybody did this.

We have been doing a lot of thinking at Snowplow [2] [3] about JSON Schema versioning and self-description. One of the key points as it relates to RESTful APIs is: it's not enough to version your API, you should be versioning the individual entities that your API returns; these entities should be able to individually evolve over time, with the focus on evolving the entities' schemas in additive (i.e. non-breaking ways) for existing clients.

There's quite a lot to learn from the Avro community in all this.

[1] https://github.com/balanced/balanced-api/tree/master/fixture... [2] http://snowplowanalytics.com/blog/2014/05/13/introducing-sch... [3] http://snowplowanalytics.com/blog/2014/05/15/introducing-sel...

Post reply on HN