Stack trace log (failed line number) printed in `cypress run` is different from the stack trace in `cypress open`
See original GitHub issueCurrent behavior:
- when run a cypress script on terminal with command:
./node_modules/.bin/cypress run --port 3019 --browser chrome --config testFiles=myCypressPath/cypress/test/20200426172648.js
I can get stack trace printed in terminal like: We can see that the log indicates the failed line number is in line 24, which is not correct - in the meanwhile when I run it with
cypress open
, it indicates that the failed line number is 31 which is correct:
Desired behavior:
how can I get correct stack trace on ternimal? I am using some automation framework to automate cypress scripts and parse the stack trace log to get failed line number
Test code to reproduce
var test1 = "http://argo-ui.oss-cn-beijing.aliyuncs.com/test.js";
var test2 = "http://argo-ui.oss-cn-beijing.aliyuncs.com/test (2).js";
var test4 = 111111;
describe('test_name', function() {
it('what_it_does', function() {
cy.viewport(1024, 768)
cy.setCookie('currentRegionId', 'test')
cy.wait(4000)
cy.visit('https://test.com')
cy.clickText('尊敬的用户');
cy.wait(3000)
cy.wait(1000)
cy.visit('https://test.com')
cy.wait(1000)
cy.get('li.J_submenu_edasAppManage > div.el-submenu__title > div:nth-child(1) > div').click()
cy.wait(2000)
cy.xpath('//div[text()="配置管理"]').click()
cy.wait(4000)
cy.visit('https://test.com/?regionNo=test')
cy.wait(2000)
cy.getIFrameBody('.J_iframe_Contianer').xpath('//span[text()="创建"]').click()
cy.wait(2000)
cy.getIFrameBody('.J_iframe_Contianer').find('#dataId').click()
cy.wait(1000)
cy.getIFrameBody('.J_iframe_Contianer').find('#dataId').clear().type('dfdfdfdfdfdfiiii')
cy.wait(1000)
cy.getIFrameBody('.J_iframe_Contianer').find('div.view-lines').click()
cy.wait(2000)
cy.getIFrameBody('.J_iframe_Contianer').find('textarea.inputarea').clear().type('fdfdfdfdf')
cy.wait(1000)
cy.getIFrameBody('.J_iframe_Contianer').find('button.next-btn-primary').click()
cy.wait(1000)
cy.getIFrameBody('.J_iframe_Contianer').find('div.next-dialog-footer > div > button[type="button"].next-btn-medium').click()
cy.wait(1000)
cy.getIFrameBody('.J_iframe_Contianer').find('button.next-btn-normal').click()
})
})
Versions
Cypress: 4.7.0 operating system: MacOS Catalina 10.15.5 browser: chrome 83.0.4103.97
Issue Analytics
- State:
- Created 3 years ago
- Reactions:14
- Comments:14 (2 by maintainers)
Top Results From Across the Web
Debugging - Cypress Documentation
Code frame file: This is usually the top line of the stack trace and it shows the file, line number, and column number...
Read more >Troubleshooting | Cypress Documentation
Another way to log what is found by Cypress is to run Cypress with the DEBUG environment variable set to cypress:launcher . This...
Read more >Error Messages | Cypress Documentation
This message means you tried to execute one or more Cypress commands outside of a currently running test. Cypress has to be able...
Read more >Cypress App
Code frame file: This is usually the top line of the stack trace and it shows the file, line number, and column number...
Read more >Good error messages - Cypress
Yet, aside from the stack frame where the assertion fails ... We have to open the file spec.js at line 4 ourselves, trace...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@jennifer-shehane any update on this?
We are facing failures in CI with references to line numbers in the file that are beyond the length of the file.
The relevant files are using ASCII encoding.
I am also facing this issue and is tremendously frustrating for the dev team. I personally feel that correct stack trace is a really important way of tracking the root cause of the issue and if it is incorrect than loads of time is required to be spent in debugging 😦 Request to prioritise this bug and address it Soon please. This is super useful when tests are been executed in headless mode and most of the times they are executed that way. OR at least give us a formula to calculate the correct line number (if any such formula exists) 😃