Yes, both VS Code and Eclipse work just fine! Maksim actually used VS Code during the demo because it’s super smooth when working with JavaScript and Node projects everything just clicks together nicely.
But if you’re more comfortable with Java and already set up in Eclipse, that’s totally okay too. The WebDriver BiDi setup works there as well it really just depends on which environment fits your workflow better.
If you ask me AI feels more like that super-efficient intern who never gets tired rather than the test lead calling the shots. It’s great at handling the repetitive, time-consuming stuff running tests, catching obvious bugs, or reacting quickly to issues but it still needs direction.
Humans bring the strategy, creativity, and context that AI just doesn’t have yet. We decide what to test, why it matters, and how to handle gray areas where judgment comes into play.
So yeah, AI is an amazing assistant one that helps you move faster and stay focused on the bigger picture but it still needs a test lead (that’s you!) to guide the way.
That’s a great question and one that came up quite a bit during the session too!
So, here’s the deal: BiDi (WebDriver BiDirectional) is mainly built for browser automation, not native apps. It’s all about enabling real-time, event-driven communication between your tests and the browser which is awesome for things like debugging or reacting instantly to browser events.
Now, when it comes to native mobile automation think Android apps or iOS apps you’d still be using tools like Espresso (for Android) or XCUITest (for iOS). These frameworks are designed to interact with the mobile OS directly, not through the browser layer.
That said, there’s an interesting takeaway here: the event-driven approach that BiDi uses could definitely inspire how we design tests in native frameworks maybe to make them more reactive or efficient. But in short, BiDi itself doesn’t directly plug into Espresso or XCUITest.
In summary: BiDi = browsers. Espresso/XCUITest = native apps. Different spaces, but similar ideas can cross over!
That’s a great question and Maksim explained it really well during the session!
With WebDriver BiDi, you’re no longer waiting for your test to finish just to dig through static logs later. Instead, BiDi lets you stream what’s happening inside the browser as it happens things like network requests, console messages, or DOM changes.
This means you can see issues in real-time, just like a live monitoring dashboard, and even react to them instantly. It’s like moving from “reading the news” about what your test did to actually watching it unfold live.
In short, BiDi blurs the line between testing and monitoring giving you live insights, not just post-run reports.
That was one of the coolest parts of Maksim’s session! With WebDriver BiDi, you basically get a live feed from the browser so the moment a JavaScript error or console log appears, you see it instantly in your test output.
No more digging through logs after the run to figure out what went wrong. It’s like having a real-time window into the browser’s behavior, which makes spotting and fixing issues so much faster. Honestly, it’s a big step up from the old way of debugging blind.
Right now, WebDriver BiDi is supported by Chromium-based browsers like Chrome and Edge, as well as Firefox. During Maksim’s session, he shared that the broader goal is to make BiDi a true cross-browser standard not just something that works well in a few browsers.
There’s a lot of collaboration happening between browser vendors to align implementations and ensure consistent behavior across all major browsers. So while it’s already in a good place, the roadmap is all about polishing compatibility and bringing Safari and others fully on board soon.
That’s a great question and honestly, one that a lot of teams are wondering about right now.
From what Maksim shared in the session, it’s pretty clear that WebDriver BiDi is where the future is headed it’s faster, more interactive, and built for the kind of reactive, event-driven testing modern browsers need.
That said, JSON Wire Protocol isn’t going away overnight. There are tons of existing frameworks and legacy test suites still running on it, so we’ll probably see both co-exist for a while. Teams will gradually migrate as tools and ecosystems fully adapt to BiDi.
So in short BiDi is the future, but JSON Wire will hang around for some time until everyone’s ready to make the jump. It’s more of an evolution than a switch.
Absolutely! One of the coolest things about WebDriver BiDi is that it gives you real-time access to what’s happening inside the browser no waiting until the test finishes to dig through logs or profiles.
You can actually subscribe to network and performance events, so as your page loads, BiDi can capture metrics like how long it takes for resources to load, when key elements render, and even runtime performance stats.
In simpler terms, instead of running your test first and analyzing performance later, you get live insights while the test is running. It’s a much faster and more efficient way to evaluate page performance, especially when you’re troubleshooting slow-loading pages or optimizing your web app experience.
Absolutely! Think about a simple form submission on a website say, a signup or checkout form. When a user hits “Submit,” the app usually makes an API call in the background to send the data to the server.
Now, with WebDriver BiDi, you can actually subscribe to network events and watch those API calls happen in real time. This means you can see what data is being sent, check if the request payload is correct, confirm the response status code (like 200 or 400), and even measure how long it takes for the response to come back.
So, if something goes wrong maybe the request never reaches the server, or the app sends incomplete data you’ll catch it instantly. It’s a great way to validate that your application behaves correctly from both a user and network perspective, especially under real-world, dynamic conditions.