I'm using Rspec/Capybara with Poltergeist as a driver to write tests for some large web applications.
My issue is that I would like to record the messages that appear on the console, but so far I've been unable to do so.
I am aware of the options js_errors and phantomjs_logger, but I have had some issues with them:
if I set js_errors: false, the file I specify in phantomjs_logger stays empty;
if I set js_errors: true, console.log messages are logged in the file specified in phantomjs_logger, but then almost all my specs fail because of
javascript errors that may not even be relevant to the navigation example I'm testing.
Any idea on how I can save the console messages while not breaking specs on every js error?
CLARIFICATION:
I have no control over the development, my task is to check the stability of the whole stack of the applications in the various environments, accessing from the front-end, so clearing out all the javascript errors is out of the question. The specs I'm writing are also supposed to ignore javascript errors if they don't impair the usage of the interface.
You can't. The PhantomJS client catches javascript error messages and adds them to an array. Then when a command completes, if js_errors == true, that array is checked and if not empty the javascript errors are returned and trigger an error in the test. There is no other API in poltergeist for accessing those errors. It sounds like you need to have a discussion with your manager about the wisdom of just ignoring JS errors if they apparently don't impair usage - it's a potentially dangerous development practice
Related
[Clarified]
I'm writing my first Laravel app using Vue components; it is a CRUD. I know how to report significant problems to laravel.log via the Log::error("There is an error") technique but that's only useful while I'm in the PHP code; as far as I can figure out, there's no way to write to laravel.log from within a Vue component. (Correct me if I'm wrong!!)
This raises the question of how I should report an error in a Vue component in a Laravel app. I know about console.log(), Debugger for Chrome, and Devtools and those are fine for development. But what about errors that might reasonably happen in production? Clearly, user errors like bad input on a form needs to be dealt with by notifying the user and letting the user correct their input but some errors are beyond the user's scope. For example, it's not hard to imagine my Vue component failing to access the database because it is down for some reason. Shouldn't that kind of problem be written to a log so that whoever monitors production apps can deal with it?
How would a professional app deal with that kind of situation?
My initial inclination is just to write it to laravel.log if possible but that may be either impossible or be considered a bad approach. I'd be curious to know what experienced Laravel developers do in such situations. Maybe automatically sending a text to a support person would be a better approach. I'm really not sure how this should be handled in a modern professional way.
In any case, whoever is responsible for situations beyond the user's control needs to be told somehow so they can begin the steps that would be necessary to fix the problem. Furthermore, this person needs to be given sufficient details of what happened to be able to solve the problem. I expect that would include things like stacktraces, error codes, etc. I wouldn't want to send all of that as a stream of texts, I'd want it all to be accessible in a log of some kind. Then, you simply notify the support person that there is a problem of such-and-such severity which occurred at such-and-such a time and remind them where to find the details.
My approach may be dated though and newer, better alternatives may exist. Those are what I'm looking for with my question.
I can give a general purpose answer for your question.
React introduced the concept of ErrorBoundary,
Error boundaries are React components that catch JavaScript errors anywhere in their child component tree, log those errors, and display a fallback UI instead of the component tree that crashed.
Using Error Boundary in Vue
use vue-error-boundary
This simple code of handleError method shows ErrorBoundary receiving a callback function through the on-error prop.
<template>
<ErrorBoundary :on-error="handleError">...</ErrorBoundary>
<template>
<script>
// ...
methods: {
handleError (err, vm, info) {
// do something
}
}
// ...
</script>
read the docs for the npm module to know more.
while handling errors, you can pass the errors to a link to your production site.
eg. /logging so it would be like https://www.example.com/logging, and post the errors in a format eg Date: Error File: Error Message.
You can even use authentication tokens along this link (though no one would use it as it would be frontend errors everyone can see it at console).
Then use routes to log those errors to laravel logs.
Firefox seems to fail on registering a ServiceWorker for Push Notifications, with an error "InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable", but the code works in Chrome and Edge, and appears to be compliant with the examples online and the spec.
I've thrown an example up on one of my test sites, https://wiegandtech.net/ - visiting it in Chrome will prompt for permission and then opt-in successfully, sending the info to the server. But Firefox prompts, doesn't complete the registration, and doesn't fire any error or throw anything into the console. When I try to debug, it seems to never return from navigator.serviceWorker.ready.then call - I debug in and reg is undefined, even though the promise says it shouldn't be. I can find no reason why this is failing. I do see in Fiddler that FF gets the worker file, so it appears to be starting the call, but never finishing? The worker is valid JavaScript, as far as I can tell. Does anyone have any documentation on how Firefox's implementation is different from Chrome's/the spec?
Firefox requires the ServiceWorker's URL to end in .js - I was using an ASP.Net site and returning javascript but through my own controller. When I just give it the URL for the .js file itself, it now works. Would file a bug, but too non-trivial to setup a site given that ServiceWorkers require a real life site to troubleshoot, and their source code doesn't appear to be on github.
I am just getting started with Play Evolutions and I find it pretty tough to figure out why they fail and leave the DB in an inconsistent state.
In Dev mode it will display the error in the default HTML page but it does not say which statement failed. This is also problematic since for this particular application I only have REST APIs that return JSON and so an HTML error is not appropriate. I have my own error handler so I will probably end up matching on ExceptionAttachment and pull out the content/script myself and escape that in the JSON error response. However this is only in DEV mode since I would not want this going back to a real user in PROD.
More frustrating is that it doesn't even log the statement when it fails. I can enable logging for my driver but once the failure has occurred it is too late to then go and enable logging.
Is there anyway to get a more specific error in the logs when an evolution fails?
Even when all tests are passing, I see many many instances of this message amid the successful test output:
...
in the single-post view
behaves like editing a comment
HTTP request failed.
HTTP request failed.
HTTP request failed.
...
What is causing it?
One possibility is that requests made by for example third-party analytics scripts on your page are failing.
You can see their activity by inspecting the output of poltergeist's page.driver.network_traffic at the end of a test.
If you think this is the problem, you could take those scripts out of the picture by
including them in the page only if you're not running tests, or
using poltergeist's page.execute_script to replace appropriate functions in those third-party scripts with no-op functions. (That takes more work but leaves the page contents more production-like, which might catch a few more possible errors.)
So I has a small problem as I outlined here.
I have made a new question because this is more general and will perhaps help others.
So essentially, I integrated the Facebook SDK Into Codeigniter as a library.
The SDK requires Json and Curl.
In the base_facebook.php file there is the following code:
if (!function_exists('curl_init')) {
throw new Exception('Facebook needs the CURL PHP extension.');
}
if (!function_exists('json_decode')) {
throw new Exception('Facebook needs the JSON PHP extension.');
}
If these functions are not available I expect an error to be fired to tell me such. Then I can install the correct packages and continue.
What actually happened is that even when I had error reporting set to E_ALL a blank page was returned.
This made it impossible to debug and after lots of playing I worked out it was because CURL was not installed on my server.
My question is why does codeigniter show blank pages rather than library based exceptions?
Furthermore even if there is an exception in a library why does the rest of the page not continue executing.
Essentially CI is seemingly making the use of exceptions worthless..
COuld anyone advise?
THanks
My question is why does codeigniter show blank pages rather than library based exceptions?
Most likely because display_errors is set to “off”.
While this is recommended for a production environment (web site users are not supposed to see internal error messages – it might give them info about internals, that they are not supposed to have) – it’s not very helpful while developing, where you as the developer want to be informed about what went wrong.
So check if CI has a “debug” setting for this, or if it’s maybe already set to off in your PHP configuration.
(Maybe CI or your config are set up in a way that errors are logged to a file instead. Also recommended for production; while developing, you’d have to keep an eye on this file then.)
Furthermore even if there is an exception in a library why does the rest of the page not continue executing.
Because that’s how exceptions are supposed to work – if they are not being caught when they reach the “top level” of your app, they cause a fatal error, and scripts die when those occur.
Familiarize yourself with the concept of try { … } catch(…) { … } to handle exceptions that might occur in script flow.
(Actually, it’s kinda surprising you don’t know all this already, if you’re working with an advanced PHP framework …)