I created a API and would like to test it. My initial thoughts was to use an API client, which I did, I used guzzlehttp, but after deploying the app to heroku and using travis and coveralls to build my test, it turns out coveralls is not able to see the part of my code covered by the test.
So my question is really "How do I test my REST API without an API Client?"
below is the link to my Github showing 0% as my test coverage
Related
My aim is to have an on line system where people can transfer money via visa direct and also pay for the services.
For this I needed to integrate to visa network. However, am having some challenges doing the same.
Well, this is what I have found to be the steps towards integrating with them:
Create a sandbox account where sample code is provided on how you can hit their end point.
My problem came when I found the sample code provided uses PHPUnit hence I have a problem testing on a browser.
The sample code generated for you can only be tested on a terminal via ./vendor/bin/phpunit.. My interest is to be able to test the same on a browser. Can this be done?
After you are done with the tests, you request them to be allowed to move to production.
I am yet to get to this stage since I am stuck at one.
A major concern is that the email provided for communication during the development journey takes days before it is responded. This makes the development journey a bit too long.
Has anyone done this before probably in PHP and would be willing to help me?
Kind regards.
Your work process should be like that:
1- Your code:
You have your webserver and php backend.
2- Visa API:
Download Visa api via Composer.
Test if the api works by itself (isolated from your backend) using phpunit.
After running phpunit, you know your installation of the API is successful. Now you're ready to use it.
Note that the API vendor Visa have already wrote the tests and added phpunit package along with their api, so you just run phpunit.
3- Integration
In your backend, instantiate a Visa API object (I think their API is a class).
Do the function calls as per their API docs.
To write your code, you need to look at API, and use help from their tests and sample codes.
4- Testing
Either use a test suit like phpunit or something else.
If it compiles, it is tested ;) // Don't do that.
I created an API using SlimeFramework then wrote test to see if results returned from the routes are accurate and also to test side effects of accessing these routes. I am making the client call with guzzle.
I am required to use continuous integration to send the information to travisCI, but travis does not have a host on which I can test my API, and guzzle requires a client(url) from which to make the route calls.
I am new to using any form of continuous integration and do not know what to do. I need help.
How do I test my API on travis?
I have written Integration tests for an application built in CodeIgniter 2.x. The tests are a Selenium + PhpUnit combination.
So far, I have used test accounts of Stripe and Amazon within the application and obviously the tests use the same accounts. I was wondering how would i go about creating Mock objects for these APIs so that i can avoid live data creation/deletion.
For Stripe, i could not find any mocking library for PHP. So stubbing the responses and requests does seem to be a good option. But again, even if i use stubs in my tests in place of real data, the application during that certain integration test will still be needing correct information for it to pass.How do i tell the application to use fake data?
Also, i would like to know if it is generally a good idea to mock objects in integration tests i.e. within the context of web applications?
This is a tool that Stripe themselves have developed for mocking Stripe.
https://github.com/stripe/stripe-mock
It runs a server on your local machine that responds to API calls in s Stripe-like fashion. This would be something you could try for acceptance tests
For PHP Unit tests, you'd be better using something like AspectMock - although config is a bit tricky. You can specify in advance what a call to a Stripe resource (e.g. \Stripe\Stripe::setApiKey, or \Stripe\Customer::retrieve) is supposed to return without hitting the Stripe servers - and you can also test whether or not your application code tried to make these calls. You can also simulate failures to test that your application behaves properly if, say, Stripe is down.
I am developing an iOS app, which stores data that the user enters in the app through an API written in PHP (using the Yii framework) in a database on a server. It works, however, I don't have any test code. I am looking into the best way to test this kind of program stack, but I cannot see the wood for the trees.
For unit testing the PHP API, I am looking into PHPUnit, which seems
to be the de facto standard for PHP. Is there a standard for unit
testing iOS code?
What would be the best way to create an
integration test case, in which I specify certain behavior in the
app, and check if the data ends up correctly in the database?
I have a shop project written with Zend Framework 2 and now I want to write an app for this project. I'm new to this whole Android thing (I wrote a few test apps, but no big project like this). So at this moment I'm planning the "app-project" but i didn't find that much till yet.
I have to write the API in PHP and the complete Android app, so I just wanted to ask if someone can show me some good tutorials/sites etc to get more information for this (there are some big topics I'd like to know like security with the JSON communication etc).
If you're building your API in PHP assess first which framework you want to use. I've had success using Yii to build a quick REST JSON API. After getting to grips with Yii this article explains in detail the process of building a REST API: http://www.yiiframework.com/wiki/175/how-to-create-a-rest-api/
You have a few choices in terms of authentication and securing your API. Firstly make sure all data is sent over https otherwise your efforts to secure your API are wasted because anyone listening on your network can read requests/responses in plaintext. Look at using OAuth or a HMAC pattern similar to Amazon web services for authenticating requests. Here's a great article on the latter: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/