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

41–50 of 51 posts

Re: TDD your API

#41

Post by pault »

Spearchucker wrote: post #37

This is great, totally see the value for an API. I'm interested to know what people use for say, native desktop apps, which is what I'm building.I ask because I've tried writing a few tests a couple of years ago, didn't see the point and haven't written any since. My code is stable, it's dogfooded every single day. Anyone have any thoughts on TDD in this kind of scenario?

I find that in order to get natural feedback early in a development cycle, you need to write so many interdependent bits of code to get something actually working that any mistakes you made along the way are buried in a mountain of spatial complexity. By testing at a lowish level along the way, you don't have to wait until there's a button to press to see if things are working as expected. Long feedback cycles make for tedious debugging sessions. I consider testing more useful as an aid for authoring code than as proof that it works after the fact, but that's a nice side effect. It also forces good separation of concerns (monolithic procedures are difficult to isolate). I don't worry about 100% code coverage; I test what I need to test to feel confident my code is working.

Edit: I also write a lot of throw-away tests as I go. I find that the easiest way to figure out how third party libraries work is to write tests against the documentation. If you find something unexpected that way, you can be pretty sure it's somebody else's fault.

Re: TDD your API

#42

Post by LnxPrgr3 »

benihana wrote: post #32
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…

>I've brought this up before, but “literature” carries the connotation of “scientific literature” to you . That connotation didn't even cross my mind. Regardless. Are you going to wait until there is a peer-reviewed scientific paper telling you TDD is good before you'll believe it? Do you have personal experience that TDD seems to make your designs better? If so, is that less true to you because we haven't scientific…

The closest thing I've seen to a proper study concludes that testing is high cost and low benefit compared to other QA measures: https://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-...

Re: TDD your API

#43

Post by mneary »

mtamizi wrote: post #40
mneary wrote: post #34

Earlier quoted context omitted.

Yeah, I realized the same thing; this aspect really makes it harder to keep the system simple, naturally. I've thought about different ways of approaching this, considering chained requests as a possibility.

Here's an example of how we do it: The scenario: https://github.com/balanced/balanced-api/blob/master/feature... : Scenario: Push money to an existing debit card Given I have sufficient funds in my marketplace And I have a tokenized debit card When I POST to /cards/:debit_card_id/credits with the JSON API body: """ { "credits": [{ "amount": 1234 }] } """ Then I should get a 201 Created status code And the response is…

That's really quite impressive! I hadn't realized that you meant that an endpoint can be referenced "in the abstract" without explicit parameters, which makes for much easier integration.

For some reason, though, I feel like the natural language would actually intimidate me. Where are ideas like "sufficient funds" defined?

Re: TDD your API

#44

Post by mtamizi »

mneary wrote: post #43
mtamizi wrote: post #40

Earlier quoted context omitted.

Here's an example of how we do it: The scenario: https://github.com/balanced/balanced-api/blob/master/feature... : Scenario: Push money to an existing debit card Given I have sufficient funds in my marketplace And I have a tokenized debit card When I POST to /cards/:debit_card_id/credits with the JSON API body: """ { "credits": [{ "amount": 1234 }] } """ Then I should get a 201 Created status code And the response is…

That's really quite impressive! I hadn't realized that you meant that an endpoint can be referenced "in the abstract" without explicit parameters, which makes for much easier integration. For some reason, though, I feel like the natural language would actually intimidate me. Where are ideas like "sufficient funds" defined?

"I have sufficient funds in my marketplace" is defined here: https://github.com/balanced/balanced-api/blob/master/feature...

  Given(/^I have sufficient funds in my marketplace$/) do
    step 'I have tokenized a card'
    @client.post("/cards/#{@card_id}/debits", {
                   amount: 500000
                 })
  end
Here's another example from the scenario above:

  Given(/^I have a tokenized debit card$/) do
    @client.post('/cards',
      {
        name: "Johannes Bach",
        number: "4342561111111118",
        expiration_month: "05",
        expiration_year: "2015"
      }
    )
    @debit_card_id = @client['cards']['id']
    @client.add_hydrate(:debit_card_id, @debit_card_id)
  end

Re: TDD your API

#45

Post by greggman »

pault wrote: post #38
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…

I don't understand how anyone can develop software with myriad moving pieces without isolating and testing each component as it is written. It's like trying to figure out why your car won't start by sitting in the driver's seat and pushing buttons. I wouldn't ever presume to tell someone else how to do their job, but I can't imagine doing it any other way. (I prefer to write out my spec in BDD style, and unit test wh…

Almost no tests :-(

https://github.com/EpicGames/UnrealEngine

Re: TDD your API

#46

Post by steveklabnik »

greggman wrote: post #45
pault wrote: post #38

Earlier quoted context omitted.

I don't understand how anyone can develop software with myriad moving pieces without isolating and testing each component as it is written. It's like trying to figure out why your car won't start by sitting in the driver's seat and pushing buttons. I wouldn't ever presume to tell someone else how to do their job, but I can't imagine doing it any other way. (I prefer to write out my spec in BDD style, and unit test wh…

Almost no tests :-( https://github.com/EpicGames/UnrealEngine

Games have such demanding architectures that I can forgive them for not testing, as writing tests for code that's not written for it is very hard.

Re: TDD your API

#47

Post by mateuszf »

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…

> You are not creating anything?

You are creating a session. That's why login could be a POST to /users/sesssions

Re: TDD your API

#48

Post by martin-adams »

mateuszf wrote: post #47
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…

> You are not creating anything? You are creating a session. That's why login could be a POST to /users/sesssions

And depending on your architecture, a user may decide to create multiple sessions to log in via different computers. Each of which can be audited within the application and remotely logged out.

Re: TDD your API

#49

Post by notduncansmith »

pault wrote: post #38
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…

I don't understand how anyone can develop software with myriad moving pieces without isolating and testing each component as it is written. It's like trying to figure out why your car won't start by sitting in the driver's seat and pushing buttons. I wouldn't ever presume to tell someone else how to do their job, but I can't imagine doing it any other way. (I prefer to write out my spec in BDD style, and unit test wh…

I work at a development firm that mostly services local corporations, and the average time we have to maintain the software we build is fairly low. My boss and I both appreciate the TDD philosophy, but when client budget constraints are what they are, TDD is one of the first things to go out the window. Our CEO has (understandably) a hard time selling a project for 20% more money when the client won't get 20% more features. Additionally, if/when bugs come up, we're able to sell support and enhancement sprints. So really, TDD would reduce the (already small) revenue stream we get from support, at the benefit of being "one of the cool kids".

Re: TDD your API

#50

Post by fit2rule »

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…

In industries such as rail and transport, industrial systems software - developed under Waterfall principles - tend towards the TDD approach, and while there may not be much academic/scientific literature on the subject, TDD is fairly well observed and applied in software industry. Because its also a 'natural act' in many other industries; you plan to fail once, improve, then pass the process, no matter if you're booting up an OS, or indeed a furnace, an accelerator, etc. Test before use, is TDD in a tl;dr, where 'use' to a developer means 'give to customer'.
Post reply on HN