feat(ct): angular component testing #27783
Conversation
sand4rt
force-pushed
the
hello-angular-ct
branch
from
aa9b3fe to
71599da
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
What's out plan here, is it ready to land? Is it based on Younes's work or is this something different? |
There was a problem hiding this comment.
Great job @sand4rt!
Here are a couple of things that would be nice to solve before merging.
Let me know if you want me to contribute to your branch directly with some PRs.
The main discussion here is about vite plugin replacement and configuration.
Hey @pavelfeldman! I just shared my feedback with @sand4rt.
It doesn't matter anymore. There was just a misunderstanding. |
|
Hey guys, thanks for the comments! I'm AFK for a couple of days. Will hopefully look at the PR by the end of next week as well |
There was a problem hiding this comment.
The added logo is the Angular.js one, here's the link to the correct Angular logo.
sand4rt
force-pushed
the
hello-angular-ct
branch
from
720980b to
71599da
Compare
Hi @edbzn, thanks for the input! Would you like to make the change by creating a PR against this branch? See #27783 (comment) for more details edit: Angular just released their new logo: https://angular.dev/press-kit |
sand4rt
force-pushed
the
hello-angular-ct
branch
from
71599da to
8ccb3bb
Compare
This comment has been minimized.
This comment has been minimized.
|
I just noticed that the tests themselves are using Angular 15. |
|
Hey @sand4rt, I just created a This way, we can update the todo list as this:
Here are the advantages of moving the Angular vite plugin setup to the
The drawbacks are:
Of course, this is just a temporary solution until the Angular team releases an official vite plugin which will at least warranty major version compatibility. |
|
Hey @sand4rt are you available in the upcoming days or weeks so we can finish this 😊 |
Hey @yjaaidi, #29544 needs to be resolved before i can update. I could resolve the merge conflicts later on if needed, so don't let that hold you back. For the people willing to contribute; beta testing would also help a lot to ensure everything operates as expected, your feedback is very welcome! |
|
Thanks @sand4rt! I think that we have everything now 😊:
Cf. sand4rt#5 |
sand4rt
force-pushed
the
hello-angular-ct
branch
from
9e88b09 to
31e8817
Compare
|
Great great great work! Thank you!! |
sand4rt
force-pushed
the
hello-angular-ct
branch
from
31e8817 to
3226aa5
Compare
|
I get errors when I try to import other values from a component file. // @/components.counter.component
import { Component, EventEmitter, Input, Output } from '@angular/core';
// adding this line
export const count = 10
@Component({
template: `{{count}}`
})
export class CounterComponent {
count = count
}
import { test, expect } from '@playwright/experimental-ct-angular';
import { count, CounterComponent } from '@/components/counter.component';
test('should mount', async ({ mount }) => {
const component = await mount(CounterComponent);
await expect(component).toHaveText(`${count}`)
});When I try to run this test I get the following error SyntaxError: Cannot use import statement outside a module
at ../src/components/counter.component.ts:1
> 1 | import { Component, EventEmitter, Input, Output } from '@angular/core';
| ^
2 |
3 | @Component({
4 | standalone: true,
at Object.<anonymous> (/Git/playwright/tests/components/ct-angular/src/components/counter.component.ts:1:1)
at Object.<anonymous> (/Git/playwright/tests/components/ct-angular/tests/update.spec.ts:2:1)
Error: No tests found.
Make sure that arguments are regular expressions matching test files.
You may need to escape symbols like "$" or "*" and quote the arguments.If I set "type: module" in package.json, then I get a different error. Lastly, if I change the test slightly: export const count = { value: 10 }I get yet another error: SyntaxError: Identifier 'CounterComponent' has already been declaredThis is very confusing! I guess this is a limitation of the playwright component test, so the solution here would be to extract the variable to another file that has no Angular imports or component usages, or to not import those values into the test to begin with and use hard coded values in the test. |
Hi @chronospatian, could you please provide a repro? |
|
@yjaaidi Here's the reproduction: https://github.com/chronospatian/playwright/blob/debug-component-usages/tests/components/ct-angular/tests/update.spec.ts I found a partial workaround. The test passes if I keep component usages and non-component usages in separate imports. I can even hold a reference to the component class itself if I import it a second time under an import alias. Neat! It would be nice if the typescript transform could discriminate between component and non-component usages in the same import statement. The test will always fail if the spec file tries to import any values from a file that contains references an Angular component with field decorators (such as Edit: Setting experimentalDecorators did not fix. I'm pretty sure you can't change Playwright's tsconfig except for baseUrl and paths. |
this is preparatory work for allowing zoneless testing
Test results for "tests 1"15 passed Merge workflow run. |
|
@dgozman we are currently waiting for a response to resolve the following comments:
We also have to take care of the following:
|
|
Hi @zargham-leanix, i think the team is busy. meanwhile, you can use our community support |
|
We are trying to make a responsible decision we would be able to stand by in the long run. Looking at the current component testing trends (https://npmtrends.com/@playwright/experimental-ct-react-vs-@playwright/experimental-ct-svelte-vs-@playwright/experimental-ct-vue), we already have reservations around the vue and svelte support viability. Hybrid frameworks are somewhat compromising the whole idea of component testing we well, which also does not make committing any easier. So please let us take time to figure out where we want to bring the component testing going forward. We would hate to add this support to Playwright only to remove it later. |
|
I'll close this PR as the decision is not in the realm of the code, so that we could go back to it when we are ready. |
|
With all the effort done by @sand4rt @yjaaidi and so many others, I really hope this functionality gets added to Playwright asap. I do understand the concerns and it is very important that those are being addressed, but while this feature has been available in Cypress for a long time now, Playwright really can not stay behind if you ask me. This it an essential part of a testing strategy which cannot be ignored. |
|
Hi @pavelfeldman, I don't think the stats are fine. If you combine the stats for cypress and PW for react you are at 200K weekly downloads. To that you can also add JEST/Testing Library mount component tests to have a good feeling how big the market is. All Enterprise companies I know are now migrating from Cy to PW because of the recent Cy decisions. What is the alternative JEST/ Testing Library ?
Then make a decision. I think PW / CT is by far the best technology and I used JEST/Tesing Lirbary / Cy Component Tests. PW CT for Web Components and works amazingly well - the best thing there is a tolerable tradeoff compared with JEST regarding performance. but you get all the cool tools and stability that make it a amazing developer experience. |
|
My 2c: (also answering @pfteter) |
|
We, JSCutlery, will keep maintaining In case Would it make sense to move |
|
@yjaaidi I invited you to the org, happy to have ct-angular there until Playwright's CT is ready. |
|
I wanted to take a moment to respond here, as this PR touches on an issue that’s been critical to the community: the future of browser-based component testing in Playwright. After four years, the community is still waiting for a decision on whether Playwright will fully commit to component testing. I understand the need for careful, long-term decision-making, but the uncertainty is holding back progress. The concerns about supporting Vue, Svelte, and other frameworks would be valid if the metrics being used to evaluate them captured the full demand. @pavelfeldman You're solely citing experimental download counts for a product you do not teach or document. C'mon man. As the former product and technical lead for Cypress Component Testing, I’ve had a front-row seat to the innovation and development of the browser-based testing space. Since leaving Cypress, I've been involved in the development of Vitest and its browser modes. Throughout that time I've consistently heard from developers across frameworks about the demand for browser-based component testing. The tools they use—Testing Library, Storybook, Vue Test Utils, and Enzyme—show just how important this feature is to the broader community. 
@Pfeter the reason that I don't mention Every time I teach a workshop, I hear the same question: “When will Playwright component testing go stable?” Recently, at VueConf US, a team lead from General Electric expressed their frustration at having to wait for a feature that they already had with Cypress before migrating to Playwright. The demand is clear—developers are ready for Playwright to catch up, but the lack of a stable component testing feature is frustrating. This PR is especially significant because critical Angular community and core team members spent a year working on and waiting for this effort to be completed. Angular has always been at the forefront of JavaScript testing, and their contribution here reflects how important this feature is. If Playwright isn’t going to move forward with first-party support for component testing, the community deserves to know, so we can focus on building the tools that will meet our needs. There's need to see code in a browser and to be able to dispatch real events to the side effects (renders/events) created in the DOM. Playwright is currently the BEST and MOST COMPOSABLE tool to create that browser environment and dispatch those actions. I'm betting that Microsoft's priorities and staffing may not align with the community's needs. Which is fine, but leads me to ask for closure. We can read the room, but it would help everyone out a lot in their respective technical discussions and the way people choose to spend their time if the team explicitly signaled their intent for the feature. Whether Playwright decides to fully commit to component testing or officially deprecate it, the important thing is giving developers the clarity they need to move forward. We’ve waited for four years, and developers need to know where to invest their time and resources. I’m rooting for progress, whether that’s through Playwright or by empowering the community to build new tooling. Thank you for your time and consideration, and for all the work that’s gone into this so far. edit: image size |
|
Hey @JessicaSachs, thank you for your response and your work on browser based component testing! I think we're on the same page here. For the past 2.5 years, i’ve been the primary force pushing Playwright component testing forward (as part time volunteer) because i (still) believe in it's potential. I completely understand the frustrations—believe me ;) |
|
A lot of folks here are disappointed that they cannot use Playwright CT on non-React renderers. Indeed, Playwright is the gold standard for testing pages and flows, so why wouldn't you want to test your isolated components using the same best-in-class tooling? However, today you can already do CT with Playwright for Angular, Vue, Svelte, and much more. At Storybook, we've built our own CT workflow based on Playwright that you can use with any renderer that Storybook supports. It's also possible to test stories directly in Playwright as @Tallyb mentions above. In addition, we've partnered with the Vitest team on a next-generation runner, which also uses Playwright under the hood, but achieves mind-bending performance and built-in coverage support thanks to great work by the Vitest team. Please check out @yannbf ’s ViteConf talk for details: https://viteconf.org/24/replay/storybook If you're interested in figuring out CT for Angular with us, please hit me up on the Storybook Discord and we'd love to continue to build on the incredible foundation that Playwright provides. |
|
Hey @JessicaSachs! It's been a while 😊 I agree with you that this is an egg and kitchen situation. I am also observing lots of people at the gate of Playwright CT waiting for the I also understand the challenges that come with the current implementation of |
|
Thanks for the active responses. A lot of us have worked together directly in the past. I know almost everyone in this thread from one context or another and appreciate all of you.
Yes! The Vitest Browser Mode effort and Storybooks what I was referring to when I said "the community carving out new tooling" and I've seen the great collaboration efforts happening between the two projects (this all happens within Discord - if others want to tune in). There's challenges in asking people to marry a particular stack and test runner, but it at least gets the job done. The dismissiveness I saw above and incorrect stats with regard to community need is what triggered me to write up a long-form post here. The tea-leaf readings I have to provide to normal application developers is what triggered me to ask for explicitness and commitment to a roadmap or vision general. Any public statement to wrap up the conversation addressing the shift in vision and scope of Playwright CT would be very welcome. No rush, just putting the ask out there. Even among folks maintaining and contributing to Testing Library and Vitest the plan for Playwright CT is unclear and you have to bring people "up to speed". From what I can tell, it seems like collaborating with the Vitest and Storybook teams on Vitest Browser Mode and a Playwright-wrapped Storybook is the technical direction forward for this problem in the ecosystem. That's all I have to communicate. I appreciate every single team and person who shows up to move the needle forward in the space. I look forward to seeing what the community will build, and I'll see you all within our various Discords 💟 |
|
@pavelfeldman I hope you can reconsider this decision and merge this PR. |
|
I'm concluding here, please correct me if i'm wrong. Since PW has deprecated CTs for vue2 and svelte in 1.49 and: I guess it's now a community effort ? |
Vue2 and Solid will be no longer updated: https://playwright.dev/docs/release-notes#other-breaking-changes. Vue2 is end of life anyway and there was not much demand for Solid component testing.
mxschmitt provided a place for us to store the code under the community organization: https://github.com/playwright-community. However, we haven't had the time to migrate everything yet, as discussions are still ongoing regarding the best approach. |
closes: #14153 and https://github.com/sand4rt/playwright-ct-angular
TODO
Enable vite-plugin-angular JIT mode: feat(vite-plugin-angular): add support for JIT mode analogjs/analog#374 (comment)Sourcemap is likely to be incorrect: a plugin (@analogjs/vite-plugin-angular)errors when transpiling: Sourcemap is likely to be incorrect: a plugin (@analogjs/vite-plugin-angular) analogjs/analog#410typeof plugin.defaultcheck: https://github.com/microsoft/playwright/pull/27783/files#diff-4592ac823d44ec894c518ba459cfab4bd544056a674739fda5fc145cdc596923R28@analogjs/vite-plugin-angularand related code and move it tocreate-playwright? feat(ct): angular component testing #27783 (comment)