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?
Related
I am a newbie in microservices and done my research on the best practices and how to upgrade from monolithic. I need now concrete steps to move forward.
I am looking to upgrade a monolithic Laravel project to Microservices.
I have started to break the app into smaller apps. So developed multiple Laravel projects each representing a service. To simplify the question:
Authentication app: used for user authentication and registration
ToDo app: used to create a todo-list with tasks for a specific user
So now I have these two apps where each has its own CRUD operations (multiple APIs).
The question is how to move these apps to AWS serverless using Lambda Functions, API Gateways and Connect to PostgreSQL (Aurora DB).
First I need either to use the SAM template or the Bref template? And how to handle that AWS Lamda does not support Laravel?
Each app has several functions in it (the first app has signup, login, reset password...) so does each one of these must be an independent Lambda function? If yes does this mean each has to be a new Laravel project and then I will have to mention the same resource to be used by SAM or Bref to have the different functions to use the same DB.
Lambda creates by default an API Gateway? If yes then shall I create a main API gateway accessible by the user-side which can call the other API gateways? (Main API Gateways filters the request and if related to authentication it redirects to Authentication Gateway that can interact with the different Authentication Lambda functions?
I Will later have definitely to add step functions with SNS queuing support but for now, I need to understand how to move the apps.
And finally, how would you recommend integrating CI/CD into the project?
Thanks for the help!
You can follow the instructions on the Bref documentation, installing both packages.
composer require bref/bref bref/laravel-bridge --update-with-dependencies
To answer your second question, it is your own choice if you want to break it down to smaller individual lambda function, or use the entire app as a function. Both can work. You may also include multiple functions per application and use an API Gateway to route specific request to the respective lambda. If you decide do just have one function, then all requests just have to be routed to the same lambda. It's your choice.
Lambda doesn't create the API gateway by default, the serverless framework does it for you if you include the following lines in your serverless.yaml file.
events:
- httpApi: '*'
I would suggest you stick with one API gateway for a simpler routing configurations. You can configure the API Gateway to route different requests to different services.
Finally you can implement CI/CD with a pipeline, using a Git repo as a trigger and configure CodeBuild to deploy your app to Lambda.
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'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
I think this question relates to most PHP API's you download and run in your application. I want to integrate the Klarna API with my CakePHP application. Now, I am not a very seasoned CakePHP programmer so my questions might be very rudimentary. But I haven't figured this out conceptually, how it works with external non-CakePHP software in a CakePHP app. Basically how do I set it up and use it.
In which folder do I put the Klarna files in my CakePHP app? Webroot?
To initialise and configure the Klarna API for use, do I simply put the Klarna code in the controller without messing about with any of the CakePHP component / plugin load procedures?
Do I then run the API code in the controller as well?
I don't need to be using cURL to talk to Klarna in this case right? The Klarna API will make the call to Klarna's servers itself?
Provided you have received testing login credentials from Klarna, this is a working example:
Download the PHP API from Klarna. The files should be placed in the "/Vendors" folder as per
Loading Vendor Files in CakePHP 2.0
& App Class, I put them in a folder named "klarna" for the sake
of organising things. Klarna API consists of quite a few files so
can be a good idea.
You'll initialise and setup the API in the relevant
controller, or I did at least. To load the vendor files do:
App::import('Vendors, 'klarna/klarna');. Given CakePHP's folder structure, I had to modify a couple of lines from the .getAddresses file example. One was previously '/transport/xmlrpc-3.0.0.beta/lib/xmlrpc.inc', became '/vendors/klarna/transport/xmlrpc-3.0.0.beta/lib/xmlrpc.inc'. Similar for the one two lines below. Remember to set the test-accounts "Shared secret" and "merchant ID" as well as having the right test-server configured. Then you can test the API against one of Klarna's test persons.
Yes, the configuration and execution of the Klarna API both happens
in the controller as per examples. It's just normal PHP code though.
We don't need to be using cURL for this API. The API takes care of the calls itself.