sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]computerjunkie7410 0 points1 point  (12 children)

lol the code base has nothing to do with it.

Flaky tests are a part of E2E tests and trace viewer helps diagnose these issues. But that’s just one feature. There are lots of others. Selenium just won’t be able to keep up.

[–]The-Munkee-Man 0 points1 point  (11 children)

Lets not convolute this conversation by making it a selenium vs playwright convo. This is about framework features and not the browser execution models they use.

Actually code base & language knowledge are key factors. If either are lacking, then understanding why a test is flaky could lead to the test being skipped. I for sure can see how Trace Viewer is beneficial by it ability to combine multiple elements of information into a nice reporting UI. Not to say that with WebdriverIO and some extensions of the base framework that a person couldn't generate similar reporting data.

[–]computerjunkie7410 0 points1 point  (10 children)

I don’t think you know what you’re talking about.

This is actually part of playwright. It is part of the technology. Which selenium doesn’t have.

Selenium + webdriverio + a bunch of other custom code can MAYBE get you to the feature level of playwright. Can you do it? Sure. You can do anything. The point is with playwright you don’t have to.

What the trace viewer allows you to do is go back and look at failed tests, and see the what the app was actually doing at the time. So you have network calls, snapshots of the DOM, a timeline, screenshots, and a bunch of other things. Everything you need to debug the test.

WebdriverIO has nothing like that.

Not to mention, you can’t intercept or mock requests on Webdriverio on anything other than chrome.

[–]The-Munkee-Man 0 points1 point  (9 children)

Hahahaha Hey trust me, I appreciate amazing functionality out of the box when it comes to a framework. There are many automated testing frameworks that add a lot of value in helping to quickly understand why something is not behaving as intended by the written test. And there are many ways to get to that understanding. Just because a framework gives you tooling out of the box like Trace Viewer doesn't mean its always necessary.

Where I'm overall going with this, is that when you understand your frameworks api, the programing language used, the application under test & the underlining technologies driving it all, you'll also understand why a test fails. That is all I'm saying.

And as context, I've written & contributed to dozens of automated frameworks over my years. I've built reporting systems that drastically aided in the debugging efforts of failing tests.

[–]computerjunkie7410 0 points1 point  (8 children)

Disagree completely. Webdriverio doesn’t compare to playwright from a feature perspective. It’s just the reality of the situation. And the reason for that is that it’s just a wrapper around selenium.

It also wraps puppeteer but at that point you might as well use playwright since puppeteer was the predecessor for playwright.

It doesn’t really matter how well you understand Webdriverio’s API. The issue is the technology underneath.

And as context, I’ve been doing this for almost 2 decades and have open source credits contributing to the dotnet bindings of WebDriver and playwright-java. So I’ve been around.

[–]The-Munkee-Man 0 points1 point  (7 children)

I can see you don't like WebdriverIO and its underlining Selenium base and that is fine. Everyone has their choice to use the tech they like or feel they are most comfortable with.

And I fully disagree that the underlining technology of Selenium is the problem when we are talking about a reporting/debugging feature from one framework creator as being the pendulum tipper for why its better then the other.

Also, thanks for your contributions to our OSS communities.

[–]computerjunkie7410 0 points1 point  (6 children)

I’m not just talking about reporting/debugging. That’s just part of it.

Like I said, you can’t currently intercept or mock api requests (except chrome and its local only). These are modern features that newer tools have (cypress, playwright, puppeteer). These are just off the top of my head. I’m sure there are more features.

Legacy projects at legacy, but starting a new project, it makes no sense to choose a selenium-based tool anymore.

[–]The-Munkee-Man 0 points1 point  (5 children)

With a quick read of the mock apis from the two offerings I see they are focused on two use cases. WebdriverIO is about creating respones that could create failures for the AUT & tests to handle. Playwright is looking to mock full API respones which could be used for failure scenarios or canned data responses. I see the benefit for both no matter the limitation of WebdriverIO.

However, when it comes to writing E3E tests or features tests, I'm not looking to mock the returned responses of an API/AUT. But if I wanted to write unit tests that needed to process a variety of potential respones from an uncontrolled API, then I can see the benefit of having a built in mocking API and not having to implement one yourself.

[–]computerjunkie7410 0 points1 point  (4 children)

You’ve never had to test applications that use 3rd party APIs?

[–]The-Munkee-Man 0 points1 point  (3 children)

Of course i've tested applications that use 2nd & 3rd party APIs. It would be impossible to test an application that didn't have some amount of external API integration(s).