Open S-Kulyk opened 1 year ago
Not ideal workaround (but I didn't come up with better solution) for chaining is to write Task extension, something like:
public static async Task<TOut> Then<TIn, TOut>(this Task<TIn> inputTask, Func<TIn, Task<TOut>> followedByFunc)
{
var inputResult = await inputTask;
return await followedByFunc(inputResult);
}
and then, in your POM class methods, you need to return Task
await page1.ClickButton1().Then(page => page.FillForm2()).Then(page => page.ValidateField3());
@wolvi19 Nice solution, thanks! Nevertheless still believe that async API is redundant in 99.99% percent of UI automation cases and Playwright users would benefit from the sync option
Agreed. This is one of the reasons I'm hesitant to move from Selenium/C# and try Playwright/C#. I don't consider the API to be as well designed and the async-only is one of the major things. I have no use of async-methods, it just forces me to add a lot of "ugly" and irrelevant syntax/boiler-plate code to keep the test code synchronous - which it of course must be in 99% of the time.
Same in our case. Async API does not play well with older sync codebases.. Much boilerplate code & tweaking is needed. Also related question from a long time ago #1755
The reasoning was pretty much covered in the following discussion thread: https://github.com/microsoft/playwright/discussions/26890 Async API doesn't bring many benefits in an automated testing context, but forces to add an additional syntax and prevents writing fluent PO classes For example, with async API we can't have a fluent chain like
page1.ClickButton1().FillForm2().ValidateField3()
Instead, it'll be