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

Hammerhead transformations break ng19 build output #3035

Open
soletan opened this issue Jan 14, 2025 · 6 comments
Open

Hammerhead transformations break ng19 build output #3035

soletan opened this issue Jan 14, 2025 · 6 comments

Comments

@soletan
Copy link

soletan commented Jan 14, 2025

What is your Scenario?

We are testing a web application's build with TestCafe in a local browser like Edge. The application has been based on Angular 17 recently. Everything was working well there. Currently we are trying to upgrade to Angular 19.

What is the Current behavior?

After upgrading to Angular 19, all TestCafe-based tests fail for the application fails to load in any test scenario.

Analysis has found that Hammerhead is transforming occurrences of location into __get$Loc(location) and it is failing to recognize certain cases in which that replacement is breaking the code.

  • This is part of code built by ng19:
    grafik

  • The highlighted part gets replaced by hammerhead:
    grafik

  • The causing code is here:
    grafik

  • The transformation fails to recognize location being declared as instance property of that class. The code in question is part of Angular, thus there is no way that we could work around this issue on our end:
    grafik

What is the Expected behavior?

  • Hammerhead should be aware of property declarations in classes when transforming code on the fly.
  • The application should load.

What is your public website URL? (or attach your complete example)

closed source ... must not share

What is your TestCafe test code?

does not apply here

Your complete configuration file

No response

Your complete test report

No response

Screenshots

No response

Steps to Reproduce

  1. build application with ng19
  2. try testing it with testcafe

TestCafe version

3.7.1

Node.js version

22.11.0

Command-line arguments

testcafe is run through gherkin-testcafe

Browser name(s) and version(s)

No response

Platform(s) and version(s)

Windows 11

Other

typescript 5.4.5

Copy link

Thank you for submitting a bug report. We would love to help you investigate the issue. Please share a simple code example that reliably reproduces the bug. For more information, read the following article: How To Create a Minimal Working Example When You Submit an Issue. We look forward to your response.

@soletan
Copy link
Author

soletan commented Jan 15, 2025

I've created a vanilla ng19 project with TestCafe set up for doing a very simple test here:

https://github.com/soletan/testcafe-ng19-example

  • npm i
  • npm run build
  • npm run e2e

@Bayheck
Copy link
Contributor

Bayheck commented Jan 20, 2025

Hello,

I managed to run your example with the Native Automation mode enabled.

Could you please clarify why you use TestCafe with the "--disable-native-automation" flag?

@inferpse
Copy link

Hello,

Having the same issue after migrating to Angular 19. Hammerhead simply cannot handle JS bundles produced by Angular 19 when not using native automation (CDP). And it seems that native automation cannot be enabled when any custom testcafe-browser-provider plugin is used.

It might be possible to workaround this problem for some projects though. For example, following .testcaferc.js allows running Hammerhead in "native automation" mode with a third-party browser provided by the playwright package:

const { chromium } = require("playwright");

module.exports = {
  disableNativeAutomation: false,
  browsers: [`chromium:${chromium.executablePath()}:headless`],
};

While package.json could omit desired browser:

"scripts": {
  "testcafe": "testcafe test.js",
  "testcafe_broken": "testcafe test.js --disable-native-automation",
},

TestCafe is not fully compatible with Angular 19+ projects at this moment because of this issue in Hammerhead.

@soletan
Copy link
Author

soletan commented Jan 22, 2025

In our use cases, there have been a reason for disabling native automation though I can barely remember what it was. Thus, I tried enabling native automation and this gets us passed that issue at least when running a test locally (not sure about CI runs). However, another issue came up a few times after that and it has been logging this to stdout after 10-20 seconds:

[TestCafe@2025-01-22 17:24:45.629] Microsoft Edge 132.0.0.0 / Windows 11
[TestCafe@2025-01-22 17:24:45.629] DEBUGGER PAUSE ON FAILED TEST:
[TestCafe@2025-01-22 17:24:45.629] Unhandled promise rejection:
[TestCafe@2025-01-22 17:24:45.629] 
[TestCafe@2025-01-22 17:24:45.629] TypeError: Cannot read properties of undefined (reading 'prepareInjectableUserSc
[TestCafe@2025-01-22 17:24:45.629] ripts')
[TestCafe@2025-01-22 17:24:45.629] at NativeAutomationRequestPipeline._getUserScripts (C:\Users\redacted\PhpstormPr
[TestCafe@2025-01-22 17:24:45.629] ojects\redacted\node_modules\testcafe\src\native-aut
[TestCafe@2025-01-22 17:24:45.629] omation\request-pipeline\index.ts:194:31)
[TestCafe@2025-01-22 17:24:45.629] at NativeAutomationRequestPipeline._respondToOtherRequest (C:\Users\redacted\Php
[TestCafe@2025-01-22 17:24:45.629] stormProjects\redacted\node_modules\testcafe\src\nat
[TestCafe@2025-01-22 17:24:45.629] ive-automation\request-pipeline\index.ts:237:44)
[TestCafe@2025-01-22 17:24:45.629] at processTicksAndRejections (node:internal/process/task_queues:105:5)
[TestCafe@2025-01-22 17:24:45.629] at NativeAutomationRequestPipeline._tryRespondToOtherRequest (C:\Users\redacted\
[TestCafe@2025-01-22 17:24:45.629] PhpstormProjects\redacted\node_modules\testcafe\src\
[TestCafe@2025-01-22 17:24:45.629] native-automation\request-pipeline\index.ts:313:17)
[TestCafe@2025-01-22 17:24:45.629] at NativeAutomationRequestPipeline._handleOtherRequests (C:\Users\redacted\Phpst
[TestCafe@2025-01-22 17:24:45.629] ormProjects\redacted\node_modules\testcafe\src\nativ
[TestCafe@2025-01-22 17:24:45.629] e-automation\request-pipeline\index.ts:357:13)
[TestCafe@2025-01-22 17:24:45.629] at Chrome.<anonymous> (C:\Users\redacted\PhpstormProjects\redacted
[TestCafe@2025-01-22 17:24:45.629] redacted\node_modules\testcafe\src\native-automation\request-pipeline\inde
[TestCafe@2025-01-22 17:24:45.629] x.ts:444:17)
[TestCafe@2025-01-22 17:24:45.629] 
[TestCafe@2025-01-22 17:24:45.629] Browser: Microsoft Edge 132.0.0.0 / Windows 11

When trying to do some investigation on this issue, it happens to work at some point and keeps working after that. So, just like in DevExpress/testcafe#7881, the issue seems to happen rather occasionally. It may be worth mentioning that the tested app is authenticating against some IDP and in the tested setup we use lots of request mocking to prevent the app from ever reaching out to any actual backend as well as the IDP by simply mocking those requests, too.

  • I tried removing code setting up a certain user role by mocking the IDP requests accordingly, but got the same issue as above.
  • Right after that I was re-running it, and this time the sole test in question succeeded.
  • So I re-inserted that code for setting up the code and it still succeeds now.
  • I added --disable-local-storage to the browser invocation which broke the whole test again, but after that the issue above came up again.

Based on that, it all feels related to either re-using authentication data found in local/session storage or having to get in touch with the IDP which results in that issue logged above.

FYI: On invoking testcafe, the browser is "edge --lang=en_US --disable-notifications --no-default-browser-check --ignore-certificate-errors --no-first-run".

To conclude for the moment, I currently doubt enabling native automation is working for us.

Enabling native automation is disabling use of hammerhead, isn't it? If so, is your intention to drop hammerhead rather than fixing its support for ng19 or any other application that happens to use "location" as an instance property in a ES class?

Copy link

We appreciate you taking the time to share information about this issue. We reproduced the bug and added this ticket to our internal task queue. We'll update this thread once we have news.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants