Hi has anyone migrated to the playwright from testcafe or has a some guideline how migration would look like? Does it take long time ? Any information or guide would be help full please. We are fornow working with testcafe writing tests in javascript and typescript. We have taken a look at this new tool playwright but we have a lot of test cases in testcafe.
Any help is appreciated =)
21 Answer
I don't know TestCafe but know it supports JavaScript/TypeScript.
I don't know how much time it will take to convert your project. Well , its your project so you know the specifics.
However , I do know certain things.
I am someone who migrated a large(5000+ tests) project from Protractor (JS wrapper framework over selenium) to Playwright successfully.
Here are my lessons learnt in the journey:
Language: This is the most important thing. As long as new and old framework implemented in JavaScript or TypeScript , we are basically overall in the same ecosystem. This implies that the most important concepts of async programming like promises and async/await can be applied in exactly the same way which is a big relief.
NodeJS: As long as new and old framework are living in nodejs ecosystem, all the external node modules(npm modules) used can be re-used mostly as is like file reading/writing, excel readers, csv/json handlers.
Test Scripts: As long you are using any standard unit test framework( Mocha/Jasmine/Jest) for your tests scripting you can almost use it as is - no change if you are only calling page object methods in scripts so your actual code is hidden & encapsulated in your page objects as it should be.
UI Objects/Locators( Css/Xpath): No matter which framework/ library/ language/ tool you use they will be same and can be used as is as they are independently created using standard CSS/XPath which is tool/framework/library agnostic.
Page Object Methods: This is the place where most changes may happen and even that can be avoided up to an extent if you have implemented custom wrapper functions over library functions to hide the implementation details.
Utility/Supporter functions: Again this depends upon how elegantly and cleanly code has been abstracted out in multiple layers to minimize the change in lowest layers only without touching any higher layers.
Test Data: Again with right strategy it can also be kept totally isolated from the framework in the form of Json/xml/csv/text data and can be fed in test scripts as needed. As long it is implemented correctly, most of it can be re- used as is.
Configuration: It's not a biggie as it's one time and not much code to change.
Take Away -
The effort it takes to migrate is directly proportional to how modular the framework is.
So always design your framework with modular approach from the beginning and abstract it out in multiple layers in such a way that each component/ class is DRY and only loosely coupled with other components/classes/objects so that any piece can be replaced/ updated easily without affecting the whole system.
ncG1vNJzZmirpJawrLvVnqmfpJ%2Bse6S7zGiorp2jqbawutJobm9uZmaCc4SOmqWyp56aeri0zmafmq6VYrivu9asZKGnp2LBsHnMop6rmaSaeqe%2BzqZkrZ2jqbCissRmq6hloKGuusPRop6hrA%3D%3D