We're looking at moving our Integration Tests for our API to CakePHP's version of PHPUnit. We need to test that the returned values from the API are sane (valid JSON, etc...)
The helper methods on the IntegrationTestCase abstract class look really useful, allowing me to simulate requests by simply calling $this->get('/articles') or similar, but from what I can tell there's no way to actually read the response to one of these requests. Am I missing something?
It seems that without the helper methods provided by IntegrationTestCase it would be much harder to make requests. So what's my best option here?
I just realised that I can do this by simply accessing $this->_response. At first I didn't think I could do this because its visibility is protected, but then I realised that I can access it because my test inherits from IntegrationTestCase.
Related
Hi I am new with Angularjs. I am reading about Angular service. I have read the following
what-is-difference-between-factory-service-and-provider and service-vs-provider-vs-factory. To me, it seems like they are just different way of achieving same goal (please correct me if I am wrong.) Now I am wondering as they all serve the same purpose which one is idea to use and considered as best practice?
Sounds like the question is when to use which. First it's important to note that they are all providers. Each is a more specialized version of the other starting with provider. factory is a specialized version of provider. value and service in turn are specialized versions of factory.
And constant and value are specialized versions of each other. Because provider is at the top can therefore can do what all the other providers do you could get away using just providers. But you would be writing a lot of unnecessary code.
Each specialized provider down the chain, if you could use it would allow you to accomplish the same thing in less code. So you could say the best practice is to use the provider furthest down the chain that accomplishes what you wanted.
Here is a high level image showing you what I mean:
(source: simplygoodcode.com)
And below is the link to the blog post the image is from that gives you additional examples:
http://www.simplygoodcode.com/2015/11/the-difference-between-service-provider-and-factory-in-angularjs/
There is no best practice, no one is going to tell you that one is better than the other (service vs factory).
Use a provider if you need to configure your service at run time (like you configure your router for example).
To when to use a factory or when to use a service, they are the same.
Factory has the easiest syntax to understand (using reveal module pattern) so that is the most common choice.
On the other hand, services are now more "useful" because they use the same syntax as the Angular 2 services, so if you plan in migrate someday, using services now will help the transition.
Me and some friends are currently doing a project where we are designing a webpage, where we do a number of api-calls using ajax.
We are using the Angular-framework, and we are wondering what is the correct architecture on where to put the API-calls. Right now we have them in our controllers, and saving the results as $scope-objects.
We are however wondering if it would actually be better praxis to have the API-calls in the model. We have been googling a lot, and can't seem to find an answer.
Encapsulating API calls in services is a good idea, but don't try to hide the fact that you are making web requests in your code. Have the services/model return descriptive promises and have your controller use the promises and handle errors gracefully. If using REST, you might want to use Angular's built in $resource factory. If the code is easy to unit test, it will be a sign that you're doing a good job. Being able to easily mock the services will make your controllers a lot easier to test.
Use case:
I'm writing system tests using Geb/Selenium (so outside of angular).
I want to decorate $http to log all requests/responses at run time.
and here's the catch: without touching the source code.
Before you rush to answer "use $provide#decorator", for example,
http://blog.xebia.com/2014/08/08/extending-angularjs-services-with-the-decorate-method/
That solution for this use case means adding a test hook into production code... that's normally a bad thing I want to avoid if possible.
Update: Geb allows you to run Javascript in the browser window. So just for the heck of it I ran the tutorial code to decorate $http. Unfortunately, it didn't work because apparently you can't re-config the app after it's been loaded. But even if it did work, this brings up another interesting point---I need to override $http before any modules have had a chance to use it.
Since decorating $http service would be the cleanest way of doing this, you can avoid polluting production code by using something like ng-constants and gulp/grunt to only add decoration code for a 'test' environment.
See related Q/A here: How do I configure different environments in Angular.js?
If you are inclined on changing this at runtime(where runtime takes place in a test environment), you may need to go 'closer to the metal' and deal with XMLHttpRequests: Add a "hook" to all AJAX requests on a page
What are the advantages and disadvantages of each? I ask so that i may make better use of the tools. Also, does HttpSocket fallback to using different ways to communicate if, for instance Curl is not available on the server?
If you need to do any kind of a request outside of a GET you will have a hard time using file_get_contents(). HttpSocket won't have any restrictions around HTTP methods or the types of data it can send. file_get_contents() can also be hampered by the allow_fopen_url configuration value being disabled. HttpSocket doesn't have these same issues.
As long as allow_fopen_url is true you could use the stream functions to make file_get_contents() do most anything, but it isn't nearly as simple as using HttpSocket in my opinion.
I like backbone very much, but I use not REST, but rpc over socket.io, so i need to customize somehow Backbone.sync logic, not to send RESTful requests, but to execute my client rpc library methods.
I found such example of Backbone.sync customization:
http://jsfiddle.net/nikoshr/4ArmM/
But not everything is clear for me. In the end Backbone.sync.call() is executed - what is it?
How does it really work? Does it just perform some GET request here, and i can just omit it (i do not have to make any requests as i am using socket), or it makes something important?
My idea is to take this example and just to insert here some rpc calls. Is it right way?
Rather than start with an arbitrary fiddle, why not take a look at the Backbone source code. It's very easy to read and very well documented. Scroll down to the Backbone.Sync section and you'll find that it isn't very hard to override.