Using TDD concepts for an application whose sole purpose to consume and download data from another RESTful API

Testing
1

I’m building a new Rails app to interact with a third party RESTful web services API. At this point its mostly making GET calls, parsing, and saving data to local db tables. I’m wondering what parts could/should be tested (and what parts, if any, could’ve been test driven development.)

What should and can be tested, or can be developed using TDD concept when building a pure RESTful API consumption Rails application?

2

The key thing when testing this kind of system is to create a fake version of the API that will return known responses that you can test against. There are a few different ways of doing this:

  • The webmock and fakeweb gems let you stub HTTP requests and return known values.
  • The vcr gem adds a layer on top of webmock and fakeweb that lets you record real HTTP requests and play them back in your tests.
  • If webmock, fakeweb and vcr aren’t enough, you can always use a lightweight web framework like Sinatra to build a fake API server that your test suite can use instead of the real API.
1 Like
3

This seems like a really good set of resources - thanks for pointing me in this direction. While I will do my own research and analysis on these gems and approach - would it be possible to comment on the amount of effort (in terms of approximate hours) it’ll / can take? Your answer will help me decide whether this is a doable task for this project and will also help to benchmark.

Additional details: I’m relatively new to Rails/(Web Dev) and have a deadline coming up. But I’d like to use the several hours (adds up fast) used for manually testing all the calls, i.e. every time I make any change and/or have to drop the database and/or add/update/edit migrations/models. to actually build a test suite.

4

Writing tests will probably slow you down in the short term, especially if you’re not familiar with it, but in the long term it has huge benefits and can save you a lot of time. The more features you add, the longer thorough manual testing will take and the more likely you are to miss something.

Without knowing the details and how fast you usually work it’s really hard to give you a specific estimate in hours (estimating software development tasks is notoriously difficult even when you do know the details!)