I'm doing e2e-tests for an app whose frontend is written in AngularJS, and these tests would typically involve filling in forms, sending the data to the backend, then updating the page and making sure that the data persists. The tests are written in protractor.
One of these tests fails, inconsistently and for no apparent reason, so I would like to get as much information for debugging as possible. So I’ve been wondering whether it’s possible at all to log the xhr POST requests that my frontend is sending to the backend during the test in question, or better yet, whether the data that are being sent by the browser can be captured and examined from within protractor? Perhaps, using the browser object? I googled, and googled, but without success.
Yes, I realise that e2e-tests are intended only to interact with the interface and that ajax requests are too low-level for such kind of tests. Yes, perhaps stubbing the whole backend out and just testing the frontend would have been much better. But please humor me. Is it possible to get the information about what is being posted by the browser to the server during e2e-tests with protractor?
Protractor uses the webdriverjs API to "drive" the browser, so it won't have access to any more information than any other Selenium webdriver app would have. See the docs here: http://docs.seleniumhq.org/docs/03_webdriver.jsp#selenium-webdriver-api-commands-and-operations
Outside of some APIs for controlling the browser (adding cookies, opening new tabs), most of the functionality in Protractor and WebdriverJS comes from running snippets of JavaScript in the browser (e.g., to inspect the DOM). So, I don't think any of that qualifies for intercepting communications between the browser and the server.
I think you might have luck using the Protractor infrastructure for injecting code/modules into the app start (this is the best doc I can find for this feature). You should be able to inject a module that can interpose on the $http calls an log them as they go (or, of course, fully mock them out).
Related
I´m using the cloudscraper package (PyPI, Github) for web requests on a site that is protected with Cloudflare.
I am well aware there are challenges that can´t be solved yet with this package, particularly the "v2 challenges" with recaptchas and so on.
However, for me, the package seems to not work at all. When I do a GET request with
s.get(my_url)
where s is a Cloudscraper session object, I often get a HTML page with this title: "Attention Required! | Cloudflare".
This is the standard Cloudflare Javascript challenge, which just checks whether the browser supports JS.
I don´t know why this happens. I made sure that
I have a 'realistic' User agent set, with Chrome set as browser argument in the
cloudscraper.CloudScraper()
constructor.
request are timed and not too fast, I wait between requests
I have all the package requirements installed, meaning besides cloudscraper itself, requests, requests-toolbelt, and js2py as engine.
There is no issues section on the Github repo.
The Javascript check is the simplest challenge that Cloudflare can throw at us. Still, this package, which has the sole purpose of solving some Cloudflare challenges, fails to even get past this simple check.
What am I overlooking? Cloudflare makes web automation a nightmare...
EDIT: Also, the Cloudflare page says 'Please enable Cookies and reload the page.' although normally cookies are automatically accepted by the request session´s RequestsCookieJar.
Sometimes it could be useful for a web application to be able to determine whether a seeming slowness in the application is due to network conditions or something else.
To make it easier to determine the cause in this kind of situation, I was thinking about creating something like a "check the connectivity" client-side script makes e.g. an AJAX call to the server and returns some useful metrics that make it easier to determine if the cause lies with the network.
But how much useful network troubleshooting could be done using a JavaScript that calls the server?
It sounds like you need a way to keep an eye on your site's performance from the end-user's perspective.
One way to do this is to have your client-side scripts include a way to log to a log aggregation site like SumoLogic. Here is a doc to reference about using client-side JavaScript to log to SumoLogic.
On your server side, you could implement a /ping API endpoint that would just immediately return true so you know how long it takes your user to at least reach your site. You can then log to SumoLogic how long that request took. You could do this with other requests as well to see which APIs are slower than others.
If you include geo-location when logging to SumoLogic, you can see how well your site performs around the world.
And if you want to get really fancy, then you should implement a custom header that your APIs understand which is a transaction token of some sort for all requests. When your server receives that header, it should use that token throughout the request's logs so you can see where things go wrong and what to do about them.
Another good site to check out for this sort of thing is New Relic - Browser Monitoring. This is much more performance-centric and you don't get the insights of your own logs, but it's an awesome app in its own right.
EDIT
As mentioned in the comments by #Bergi, you could also have your server respond with the headers immediately and measure performance that way.
I am trying to checkout using PayPal in sandbox environment in my script in JMeter.
It throws an error in the response tree as were sorry, but to checkout using PayPal, you need to turn on javascript and enable cookies in your web browsers settings.
Load testing PayPal is not the best idea, I would recommend leaving it to PayPal QA engineers and focus solely on your application. Even if you figure out that PayPal operations are slow - I don't think you will be able to do anything with it.
In regards to your question itself: well-behaved JMeter test must represent a real user using real browser as close as possible with all related stuff (cookies, headers, cache, think times, etc.). So first of all add HTTP Cookie Manager to your Test Plan.
Also be aware that according to JMeter main page:
JMeter is not a browser, it works at protocol level. As far as web-services and remote services are concerned, JMeter looks like a browser (or rather, multiple browsers); however JMeter does not perform all the actions supported by browsers. In particular, JMeter does not execute the Javascript found in HTML pages. Nor does it render the HTML pages as a browser does
So if the application you're testing is built using AJAX technology don't expect JMeter to create and send JavaScript-driven requests, you will need to add HTTP Request samplers to mimic them.
Check out How to make JMeter behave more like a real browser article for more tips and tricks
I'm developing a web application with Symfony2. I need to create a push notifications sysmte (like Facebook). When an user publish something, I need some of another users receive a notification.
I saw that Node.js it's the easiest manner to do this. But, I did some simple examples and all works fine, but I don't know how can I integrate this node.js application with my Symfony2 application, or really with a PHP application.
Anybody can help me?
Thanks in advance!
Please note that you've not given enough details, so I will respond as a front-end developer and not as a mobile developer
Integrating NodeJS and PHP (in general) is not a good way since you need to launch both servers separatly, create the websocket server in JS while your application is in PHP and finally create a request (GET or POST) from your PHP to you JS server. Well, a big mess, so I'll expose my solution here under.
Quick insight for mobile apps. Well, technically, there's no easy way. You can use the Push "protocol" (http://www.wikiwand.com/en/Push_technology) with NotificationPusher (https://github.com/Ph3nol/NotificationPusher). I didn't used it before so I can't help you with it.
In general.
Most of the time when people thinks of Push, long polling will do the trick. For starters it means that the request is made client-side and the server don't send data & close connection until there's new data.
How do you implement this ?!?
Basically, you change the max_execution_time using ini_set or set_time_limit to a very long time for the current script and launch a loop (like a do..while) with a sleep and the check to your data inside. From your Javascript just make an Ajax call, for example with jquery: $.get. Just remember to remove the timeout and stay in asynchronous mode.
The only drawback of this solution is that you will always have a connection opened to your server which will consume a bit more of battery on a mobile device. If you have multiple types of data to receive do not hesitate to merge the calls and publish a type in your response data, since most of the browsers allows only 2 or 3 simultaneous connections to the same server.
I sounds like your describing WebSockets.
Take a look at Socket.io, its a module for node.js.
Also there is a example at GitHub https://github.com/Automattic/socket.io/tree/master/examples/chat
Interesting files for you should be the index.js and the public/main.js.
You can see the example live at http://socket.io/demos/chat/
While I was developing some web apps, to me it became optimal to use a web service to interact with the server, and the rest I was enjoying to do with client side (JQuery). but when I was testing my code, I encountered a huuge hole in it, and i don't know how to prevent it.
The problem is that I can easily inject javascript and run any functions including webmethods from firefox's firebug tool.Is it a something known, and what should be done to prevent it.
THank you
This is not a hole at all. The client can only run JavaScript code on the page that they have downloaded from you on their own computer. It has no affect on your site at all.
As for the ability for them to make requests via JavaScript -- well, they can make requests via the browser too. What's the difference? Just make sure that your server properly validates all requests -- it should treat any request as if it were as malicious as possible.