I'm writing function unit tests for a REST API built with Symfony2. Part of the REST API checks HTTP basic authentication against a third party web service.
This presents a bit of a challenge when it comes to unit testing as I can't create a temporary user for the third party web service.
I could hard code credentials in, but I was thinking of an alternative approach. Would it be bad practice to hard code in some logic that shortcircuits the third party API call if the environment is test? Is there a better way to do something like this? I'm sure other applications face this problem.
The best practice is to :
Isolate the authentication against the 3rd party WS in a new class
Make a mock for that class for your tests
Use dependency injection so that for your unit test, you can use your mock
Related
I am using the functional tests of Codeception to test the routes of my REST application. In a few of my routes I use a third party REST API to get some data. To speak with this third party API I use a composer package published by the same party. Normally you would use a http mocker to fake the API calls to test it. The problem is that the domains are hardcoded in the composer package, so that I can't change them with a environment variable.
How could I go about testing my routes without using the real API calls?
I am working on an API authentication project. Authentication is achieved by adding a client certificate to the https request to the api. Everything works great when I curl to my api using my client certificate and Lumen actually made it trivial to do.
What is not so trivial is unit testing this.
Does anyone know how to make an HTTPS connection in a unit test?
The callSecure method seems to have disappeared since the last version of lumen.
Assuming the HTTPS connection is made - does anyone know how to easily set the certificate. I was hoping I could just get the unit test framework to set up the correct $_SERVER superglobal values so I could use a data provider to send several different certificate errors.
I'd also like to mock the models the controller is injected with so I provide known data in my data providers without having to do any database manipulation.
What I do not want to do is write some methods to make an entire curl request using real certificates.
So - apparently this can not be done as simply as I wanted. In order to test the unit of code in question I have had to add a "getter" to return a copy of the $_SERVER array. In my unit test I then mock the controller object and override the getter to return data I can control. Then rather than using the call method in the test I just directly call the method I am testing.
It has added complexity in terms of having to do more development within the production code just so I can have some tests - however that additional development time will be well worth it in the future.
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'm wondering if there is some way to do unit testing using the Google API for authentication using the Google API PHP Client.
Here is the kind of code example that I want to use around my unit testing case.
(but i want to do more complicated things around it of course that is why i need to do unit testing)
http://code.google.com/p/google-api-php-client/source/browse/trunk/examples/userinfo/index.php
It is messy, but possible. It is not going to be exactly unit testing, but still...
You need to
either write stubs for the parts of your code which do actual
requests to the google api, which would return predefined responses
which your code needs to be ready for.
or create a simple separate
service in your local network which would behave like google api web
service. It is easier than it sounds - a simple php script with a
switch and a readfile(responseFileNumberN)...
Either way you need to decide which of google's behaviours/errors you need to emulate. Testing on live service is a bad idea. This way you are going to test google's api which is out of your control or your network connection, not your app.
What are good practices of unit testing facebook Canvas applications ?
Lets say you have MVC application with controllers utilizing local Facebook library which provides access to Graph API, FB session. After all your application depends on facebook authentication mechanism (OAuth and Facebook Connect) thus user is required to authenticate before proceeding.. How would you go with unit tests for controllers ? One thing comes to my mind - having a Facebook library with 'testing' mode and fake session might do the job. Any ideas are appreciated.
When I had this problem, I just wrapped the Facebook library calls in an object (or a set of functions functions), and used a mock of that object in the unit tests.