Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TDD your API

blog.balancedpayments.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: TDD your API

#21

Post by protomyth »

shadowfiend wrote: post #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 scie…

> “literature” carries the connotation of “scientific literature”

> there seems to be relatively little actual “literature” in the most commonly used sense.

Literature: books, articles, etc., about a particular subject

I don't think you should add words to what people have said to make a point unless you get some clarification from the author that the additions actually clarify what they said. There have been quite a few books and articles about TDD.

Re: TDD your API

#22

Post by IgorPartola »

So I recently created a simple RESTful API. Nothing fancy here in 90% of the resources. 10% do some funky things (BTW, which HTTP verb should /login use? POST? You are not creating anything? PUT? PATCH?! Really it should be a GET in this case as I am just retrieving a pre-generated token...). I did add a set of tests to keep me honest about what the API should do. I added them after the API was completed, and based on the assumptions I would be making when working on the client-side part of the app. I figured the tests wouldn't show anything: I just wrote the API so any quirks/weirdness should be carried over to the tests. Boy was I wrong. Several subtle but important bugs did immediately appear. It is tough to test a sufficiently complex read/write API as mocked objects get more and more complex, but for this relatively simple case it was worth it from the ROI point of view.

Re: TDD your API

#23

Post by mahmoudimus »

(Balanced employee)

I love TDD. Not because I write a lot of tests, but, because it helps my mind reason about proper composition and develop modular and clean APIs.

Using it as a design principle creates better software and you get a nice bonus -- regression testing for your assumptions.

It also serves as one vector of documentation -- though it's not the best.

Re: TDD your API

#24

Post by benwoody »

I'm not sure if it's legit or not to show off your work on HN, but I recently made a VERY small ruby DSL to test RESTful JSON services.

We started having a LOT of trouble with 3rd party services breaking their JSON contracts, so I started using this to test on our Jenkins CI every night to make sure their JSON was constructed properly.

https://github.com/benwoody/api_pi

It also helps our front-end/mobile developers make sure the backend devs are creating proper JSON based on specifications.

Re: TDD your API

#25

Post by ryanfitz »

IgorPartola wrote: post #22

So I recently created a simple RESTful API. Nothing fancy here in 90% of the resources. 10% do some funky things (BTW, which HTTP verb should /login use? POST? You are not creating anything? PUT? PATCH?! Really it should be a GET in this case as I am just retrieving a pre-generated token...). I did add a set of tests to keep me honest about what the API should do. I added them after the API was completed, and based o…

I recently created a login flow for a RESTful API. The solution I went with was instead of thinking of it as a high level activity such as login, what I was really doing was creating auth tokens to then be used in the Authorization header in subsequent requests.

I created a /tokens endpoint, where I POST the auth credentials and in return I get back a newly generated auth token. In my opinion this is a nice RESTFul solution.

Re: TDD your API

#26

Post by marbemac »

I'm a big believer in testing APIs. As mentioned in the post, these tests can serve a similar purpose as integration tests, and can double as documentation and API health checks.

I've been building a tool that makes it easier to work with HTTP resources. While it's definitely not finished, I've put it online temporarily if anybody wants to check it out:

http://morning-anchorage-3682.herokuapp.com/

It lets you define environments, http resources, and tests to be run against those resources. Custom headers, params, and persistent variables (to be used in subsequent tests) is all in there (although there is no help or handholding right now). There is also a command line tool that lets you connect your local sever to the service, and run the tests against your local environment.

Please excuse the un-styled login/signup screen, I added it just now to put the app online. Also.. this is a very early preview that I did not intend on putting online so early, there will be bugs. I'll be taking it offline this weekend.

Re: TDD your API

#27

Post by marcosdumay »

npsimons wrote: post #18
shadowfiend wrote: post #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 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.

Development is creative, but answering the questions "does my program work?" and "why is my program not working?" always feels like science.

Re: TDD your API

#28

Post by mtamizi »

It feels so good to see some of the comments here and elsewhere on our approach at Balanced. I've been trying to put this process/system in place for close to two years now. Steve was finally able to make it possible where I couldn't.

There's a lot of other companies facing the same challenge and have also come to the conclusion that there isn't a sufficient solution pre-built. Hopefully, we'll get to the point where there's a standard solution that everyone can use instead of tons of homegrown solutions.

Re: TDD your API

#29

Post by e1g »

shadowfiend wrote: post #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 scie…

"Making Software" [1] has a chapter called "How Effective is Test-Driven Development?" where they do a meta review of 32 clinical studies on TDD pulled from 325 reports. They filtered out reports based on scientific rigour, completeness, overlap, subjectivity etc, and ended up with 22 reports based on 32 unique trials. "TDD effectiveness" was defined as improvement across four dimensions - internal code quality, external system quality, team productivity, and test quality - and each dimension is strictly defined in sufficient detail.

They report that high-rigour studies show TDD has no clear effect on internal code quality, external system quality, or team productivity. While some studies report TDD has a positive impact, just as many report it has a negative impact or makes difference at all. The only dimension that seems to be improved is "test quality" - that is, test density and test coverage - and the researches note that the difference was not as great as they had expected.

The chapter concludes that despite mixed results, they still recommend trialling TDD for your team as it may solve some problems. However it is important to be mindful that there is yet no conclusive evidence that it works as consistently or as effectively as anecdotes from happy practitioners would suggest.

The meta-study is relatively short and can be read online [2].

[1] http://www.amazon.com/Making-Software-Really-Works-Believe/d...

[2] http://hakanerdogmus.net/weblog/wp-content/uploads/tdd-sr-bo...

Re: TDD your API

#30

Post by steveklabnik »

e1g wrote: post #29
shadowfiend wrote: post #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 scie…

"Making Software" [1] has a chapter called "How Effective is Test-Driven Development?" where they do a meta review of 32 clinical studies on TDD pulled from 325 reports. They filtered out reports based on scientific rigour, completeness, overlap, subjectivity etc, and ended up with 22 reports based on 32 unique trials. "TDD effectiveness" was defined as improvement across four dimensions - internal code quality, exte…

Coincidentally, I am currently reading that book, but had not gotten to that part yet. Thanks!
Post reply on HN