英文:
Converting WebDriverIO test scripts to a playwright scripts
问题
我正在尝试将webdriverIO脚本转换为playwright脚本。两者都是JavaScript编写的。我想知道你们中是否有人已经转换过这种类型的项目，是否遇到过任何转换器项目？
我已经开始手动将其翻译成playwright。如果可能的话，我正在寻找一种快速的方法。
英文:
I am trying to convert webdriverIO scripts to playwright scripts. Both are in JavaScript. I’d like to know if anyone of you have converted this type of project and is there any converter projects you encountered?
I already started manually translating to playwright. I’m looking for a quick way if possible
答案1
得分: 0
因为WDIO（Selenium）有不同的代码风格，所以你必须手动完成这个操作。只有Puppeteer看起来差不多一样。
请查看https://playwright.dev/docs/protractor，因为它更接近WDIO。
英文:
You must do this manually because WDIO (Selenium) has a different code style. Only Puppeteer is more-less looks the same.
Check https://playwright.dev/docs/protractor, since it's more close wdio.
答案2
得分: 0
不和是的。
不 - 至少我不知道有任何自动为您转换的东西。
是 - 您可以使用正确的策略“重用”大量代码。
我是谁？ - 我是最近成功将一个大型（5000+个测试）的框架从Protractor迁移到playwright的人。
以下是我学到的教训：
语言：
这是最重要的事情。只要新旧框架都是用JavaScript或TypeScript实现的，我们基本上处于同一个生态系统中。
NodeJS：
只要新旧框架都存在于Node.js生态系统中，大多数外部Node模块都可以基本原样重用。
测试脚本：
只要您在测试脚本中使用任何标准的测试框架（Mocha/Jasmine/Jest），您几乎可以将其“原样”使用 - 如果您只在脚本中调用页面对象方法，那么您的实际代码将被隐藏并封装在页面对象中，正如应该的那样。
对象定位器（Css/Xpath）：
无论您使用哪种框架/库/语言/工具，它们都是相同的，可以原样使用，因为它们是独立的。
页面对象方法：
这可能是发生最多变化的地方，即使如此，如果您已经实现了自定义包装器函数以隐藏实现细节，甚至可以在一定程度上避免这种情况。
实用程序/支持函数
再次取决于代码是否以多层次的方式优雅而干净地抽象出来，以在仅触摸最底层而不触摸任何更高层的情况下最小化更改。
测试数据：
再次，通过正确的策略，它也可以完全与框架隔离，以Json/xml/csv/text数据的形式提供给测试脚本，根据需要使用。只要实现正确，大部分可以原样重用。
配置：
这不是一个大问题，因为它是一次性的，需要更改的代码不多。
这其中的关键点是 - 从一开始就采用模块化的方法设计您的框架，并以多层次的方式抽象它，以使每个组件/类与其他组件/类松散耦合，以便可以轻松替换/更新任何部分而不“影响”整个系统。
我希望这有所帮助。
英文:
No and yes.
No - Atleast I am not aware of anything like which automatically converts it for you.
Yes - you can reuse lot of code with right strategy.
Who am I? - I am someone who have migrated an large (5000+ tests) framework from Protractor to playwright successfully recently.
Here are my lessons learnt:
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.
NodeJS:
As long as new and old framework are living in nodejs ecosystem, all the external node modules used can be re-used mostly as is.
Test Scripts:
As long you are using any standard 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.
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 independent.
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.
The key take away from this is - design your framework with modular approach from beginning and abstract it out in multiple layers in such a way that each component/ class is only loosely coupled with each other so that any piece can be replaced/ updated easily without affecting the whole system.
I hope it helps.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论