Expose a Test API for integration testing

[NoelAbrahams]

Hi,

This is related #2, but unlike that suggestion, I would like to see if Blitline can provide a web service that does the following:

• Accepts and authenticates the request.
• Parses and verifies the request payload.
• Returns a mock result appropriate for the request.

This would permit integration testing - to the effect the developer can be certain that when the connection is switched to production the margin of error is small, because blitline has been verifying the request in development.

Ideally this service should be provided free, without adding to the processing hours.

I believe this would be mutually beneficial. Developers running automated testing only use minimal blitline resources. And testing does not incur any processing hours.

For an example of another API that provides a similar test mode, see Twilio.

Thanks.

[blitline-dev]

Although not document on the website yet, there is way to accomplish this, which is by setting your "application_id" to "test_job". This should perform all the appropriate job posting validations, skip the "queue" and return a job post result response.

[NoelAbrahams]

@blitline-dev, thanks for the tip. I've tried it out and it's quite useful. There are some differences from the way the live account works, which makes it a bit difficult to integrate (i.e. it's necessary to have a different workflow for the test account and the live account).

• The result is return directly rather than through the long poll.
• The live result is a JSON object encoded in a string (see #9 ) while the test result is a JSON object.
• The original_meta property is missing in the test account result.

[blitline-dev]

"The result is return directly rather than through the long poll." - This is true, it returns only the response from submitting a job, and doesn't properly handle the long poll redirect. We will update the server to look for long polling on the test_user condition and stub out a long poll result in the response.

"The live result is a JSON object encoded in a string (see #9 ) while the test result is a JSON object." - This is a legacy effect of our longpolling platform only returning text MIME type instead of JSON. The node module needs to be updated to handle the long polling redirect and convert into JSON object.

"The original_meta property is missing in the test account result." - Part of the 1st issue above. This should be handled by a small server change in regards to the test_user condition.

[NoelAbrahams]

@blitline-dev, did this ever get fixed?

[blitline-dev]

I believe so. For example:

curl 'http://api.blitline.com/job' -d json='{ "application_id": "test_job", "src" : "http://www.google.com/logos/2011/yokoyama11-hp.jpg", "v" : 1.21, "longpoll" : true, "functions" : [ {"name": "blur", "params" : {"radius" : 0.0, "sigma" : 2.0}, "save" : { "image_identifier" : "MY_CLIENT_ID" }} ]}'

returns

{ "original_meta": { "width": 720, "height": 960 }, "images": [{ "image_identifier": "MY_CLIENT_ID", "s3_url": "http://blitline.s3.amazonaws.com/2016041422/test_app/this_file_will_be_autodeleted_in_24hrs_8zXkAduzXitPQsvlnXpf4Aw.jpg", "meta": { "width": 500, "height": 600 } }], "job_id": "8_m5bjyJ9IBctwXRBrTJYTg" }

Although from re-reading through this, it sounds like there was other functionality you were interested in, some of which would probably need to be addressed somewhat through the gem/npm libraries for blitline clients.