OnBefore casper script randomly failing
- Dominant language
- JavaScript
- Stars
- 7.2k
- Forks
- 621
- PR merge metrics
- No merged PRs in 30d
Description
I'm wanting to use the `onBefore.js` script to set up event listening for casper to report on `report.message`, `resource.error` and so on. The issue I'm having is that I find that after a run or two, these lines suddenly prevent the `backstop test` from running, and I'm getting nothing in the way of a helpful error message. I can't tell whether its a factor of time or something else that has it working again after a while - as I've often rewritten the event capturing in different ways till it somehow starts working again.
My `onBefore.js`:
``` javascript
module.exports = function (casper, scenario, vp) {
casper.on('resource.error', function(err) {
casper.echo('resource.error occured', 'ERROR')
})
}
```
My terminal output:
```
james -> backstop test
BackstopJS CWD: /my/project
BackstopJS loading config: /my/project/backstop.json
COMMAND | Executing core for `test`
Running CasperJS with: [ '/usr/local/lib/node_modules/backstopjs/capture/genBitmaps.js' ]
CasperJS: Debug is enabled!
CasperJS: [info] [phantom] Starting...
CasperJS:
CasperJS: [info] [phantom] Running suite: 96 steps
CasperJS: [debug] [phantom] Navigation requested: url=about:blank, type=Other, willNavigate=true, isMainFrame=true
CasperJS: [debug] [phantom] url changed to "about:blank"
Testing script failed with code: 1
An unexpected error occured. You may want to try setting the debug option to `true` in your config file.
COMMAND | Command `test` ended with an error
COMMAND | Error: An unexpected error occured. You may want to try setting the debug option to `true` in your config file.
at ChildProcess. (/usr/local/lib/node_modules/backstopjs/core/util/createBitmaps.js:63:18)
at emitTwo (events.js:106:13)
at ChildProcess.emit (events.js:191:7)
at maybeClose (internal/child_process.js:852:16)
at Socket. (internal/child_process.js:323:11)
at emitOne (events.js:96:13)
at Socket.emit (events.js:188:7)
at Pipe._handle.close [as _onclose] (net.js:492:12)
```
The general issue is that there is very little visibility when things go wrong. A misspell of `casper` in the `onReady` script for example will raise the same unhelpful error. Through JS linting, these kinds of errors can be reduced - but it still leaves you in a position where your at a loss when things go wrong.
I'm aware that there appears to be a known issue with [PhantomJS silently failing](http://stackoverflow.com/questions/35634208/silent-errors-in-casperjs) - I'm assuming this is playing a part here. Although I can't see these unhelpful errors being the accepted norm as it's difficult being productive without the visibility on errors.
Would greatly appreciate assistance in getting to the bottom of the above issue.
Thanks for the awesome project.
Contributor guide
Research direction
Reproduce the failure with the supplied onBefore.js event listener and debug enabled in backstop.json. Start by tracing the test command through capture/genBitmaps.js and core/util/createBitmaps.js, comparing the reported child-process failure with the CasperJS output. Done means the failure exposes a useful error for malformed or failing scripts, with the intermittent listener case understood.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- testing
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100