Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TestCafe hungs if the overriden method of the RequestHook raises an error #3786

Closed
marcinlesek opened this issue May 13, 2019 · 7 comments
Closed
Assignees
Labels
STATE: Auto-locked An issue has been automatically locked by the Lock bot. TYPE: bug The described behavior is considered as wrong (bug).
Milestone

Comments

@marcinlesek
Copy link

marcinlesek commented May 13, 2019

What is your Test Scenario?

edit: When I added URL Filter to Hook, it's works - so case is only without it.

I'm trying to add custom HTTP header without any URL filter to few fixtures or tests.

What is the Current behavior?

The whole fixture couldn't load and hang on TestCafe splash screen with CONNECTED information. When I removed .requestHooks(hook); from fixture or test chain, it's work as expected.

When we'll check network info during loading, TestCafe is still sending requests to browser heartbeat (Request URL: http://192.168.1.183:52055/browser/heartbeat/7bPNpzU) and get 200 OK with response but without url property value:

{  
   "code":"ok",
   "url":""
}

What is the Expected behavior?

Fixture or test with .requestHooks(hook); method should load and execute properly.

What is your web application and your TestCafe test code?

I'm using your example test and example HTTP request hook to easily allow to reproduce it.

Your website URL (or attach your complete example): http://devexpress.github.io/testcafe/example

Your complete test code (or attach your test files):
import { Selector, RequestHook } from 'testcafe';

class MyHeaderHook extends RequestHook {
  constructor() { // btw. TestCafe crew, you could remove constructor from your docs here, it's useless when you're not passing requestFilterRules or responseEventConfigureOpts
    // No URL filtering applied to this hook
    // so it will be used for all requests.
    super();
  }

  onRequest(requestEvent) {
    requestEvent.requestOptions.headers['MyHeader'] = 'MyHeader value';
  }
}

const myHeaderHook = new MyHeaderHook();

fixture`Getting Started`
  .page`http://devexpress.github.io/testcafe/example`
  .requestHooks(myHeaderHook);

test('My first test', async (t) => {
  await t
    .typeText('#developer-name', 'John Smith')
    .click('#submit-button')

    // Use the assertion to check if the actual header text is equal to the expected one
    .expect(Selector('#article-header').innerText).eql('Thank you, John Smith!');
});
Your complete test report:
$ ./node_modules/.bin/testcafe scenarios/hook-test.js
The "src" option from the configuration file will be ignored.
 Running tests in:
 - Chrome 74.0.3729 / Mac OS X 10.14.4

 Getting Started
^CStopping TestCafe...

I forced exit due to few minutes without any result.

Screenshots: Screenshot 2019-05-13 at 11 26 24 AM
Config file:
{
  "browsers": [ "chrome" ],
  "src": "scenarios",
  "reporter": [
    {
      "name": "spec"
    }
  ],
  "screenshotPath": "screenshots",
  "takeScreenshotsOnFails": true,
  "screenshotPathPattern": "${DATE}_${TIME}/${TEST}/${USERAGENT}/${FILE_INDEX}.png"
}

Steps to Reproduce:

  1. Copy whole fixture with hook class
  2. Copy config file to .testcaferc.json
  3. Run TestCafe via $ ./node_modules/.bin/testcafe
  4. Check that TestCafe couldn't fixture/test page

Your Environment details:

  • testcafe version: 1.1.4
  • node.js version: v10.14.2
  • command-line arguments: -
  • browser name and version: Chrome 74.0.3729
  • platform and version: Mac OS X 10.14.4
  • other: -
@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label May 13, 2019
@marcinlesek marcinlesek changed the title Creating a Custom HTTP Request Hook makes TestCafe infinity stuck on URL load Creating a Custom HTTP Request Hook without URL filter makes TestCafe infinity stuck on URL load May 13, 2019
@AlexKamaev AlexKamaev self-assigned this May 13, 2019
@AlexKamaev
Copy link
Contributor

I was able to reproduce the issue. I think it's not a valid scenario to pass nothing to the RequestHook constructor. Anyway, TestCafe should not hang in this case, so I think it is a bug and we'll discuss a possible solution with the team. Thank you for your report.

@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label May 13, 2019
@AlexKamaev AlexKamaev added the TYPE: bug The described behavior is considered as wrong (bug). label May 13, 2019
@AlexKamaev AlexKamaev added this to the Planned milestone May 13, 2019
@marcinlesek
Copy link
Author

Thanks @AlexKamaev. If passing nothing to RequestHook is not valid scenario, please also fix this docs example which is invalid: https://devexpress.github.io/testcafe/documentation/test-api/intercepting-http-requests/#creating-a-custom-http-request-hook

class JwtBearerAuthorization extends RequestHook {
    constructor () {
        // No URL filtering applied to this hook
        // so it will be used for all requests.
        super();
    }

    onRequest (e) {
        e.requestOptions.headers['Authorization'] = 'generate token here';
    }
}

Thanks in advance!

Best regards,
Marcin

@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label May 13, 2019
@AlexKamaev
Copy link
Contributor

We have not discussed this issue with the team yet. Once we study the case, we will correct the description given in the documentation if required. Thank you for pointing this out.

@need-response-app need-response-app bot removed the STATE: Need response An issue that requires a response or attention from the team. label May 14, 2019
@miherlosev miherlosev modified the milestones: Planned, Sprint #34 May 29, 2019
@AlexKamaev
Copy link
Contributor

I discussed the issue with the team and it looks that it's valid to pass nothing to the Request Hook constructor. Sorry for this misstatement. Your code hangs because you do not override the onResponse method, since it should be implemented (at least it can be empty).
Obviously the example from the docs is incorrect so we'll fix it as well.
 

@AlexKamaev AlexKamaev removed their assignment May 30, 2019
@marcinlesek
Copy link
Author

Thanks for clarification 👏

@need-response-app need-response-app bot added the STATE: Need response An issue that requires a response or attention from the team. label May 31, 2019
@miherlosev miherlosev removed the STATE: Need response An issue that requires a response or attention from the team. label May 31, 2019
@miherlosev miherlosev self-assigned this May 31, 2019
@miherlosev miherlosev changed the title Creating a Custom HTTP Request Hook without URL filter makes TestCafe infinity stuck on URL load TestCafe huns if the overriden method of the RequestHook raises an error May 31, 2019
@AndreyBelym AndreyBelym modified the milestones: Sprint #34, Sprint #35 Jun 17, 2019
@AndreyBelym
Copy link
Contributor

Closed by #3868.

@marcinlesek marcinlesek changed the title TestCafe huns if the overriden method of the RequestHook raises an error TestCafe hungs if the overriden method of the RequestHook raises an error Jun 17, 2019
@lock
Copy link

lock bot commented Jun 27, 2019

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.

@lock lock bot added the STATE: Auto-locked An issue has been automatically locked by the Lock bot. label Jun 27, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 27, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
STATE: Auto-locked An issue has been automatically locked by the Lock bot. TYPE: bug The described behavior is considered as wrong (bug).
Projects
None yet
Development

No branches or pull requests

4 participants