I’m trying to set up performance tests for a service that doesn’t have any REST endpoints. It uses websockets to get data and show it in the UI. I was thinking maybe we could use a headless browser to take screenshots of the UI and then use those for Gatling tests. But I’m not sure if this is possible or makes sense.
The problem is that Gatling usually needs endpoints or sockets to test. My service doesn’t have much exposed for testing. So I’m wondering if we can somehow mix a headless browser with Gatling to make test calls and check performance.
Has anyone tried something like this before? Is it even doable? Any tips or ideas would be really helpful. I’m kind of stuck on how to approach this testing setup.
hey, i’ve done somethin simlar before. gatling can be used with headless browsers by hooking up selenium or puppeteer. you’ll need custom code to sync them, and it can be a bit slow compared to api tests. good luck!
While Gatling isn’t designed for headless browser testing, there’s a workaround that might suit your needs. You could use a tool like Puppeteer or Playwright to control a headless browser, capture screenshots, and measure performance metrics. Then, feed this data into Gatling for analysis and reporting.
This approach would involve writing custom scripts to orchestrate the headless browser interactions and pipe the results to Gatling. It’s not a native solution, but it can work for your WebSocket-based service.
Keep in mind this setup will be more resource-intensive than typical Gatling tests. You’ll need to carefully manage browser instances and ensure clean teardown after each test run. Also, consider the added complexity in debugging and maintaining such a hybrid system.
If possible, I’d recommend exploring ways to expose some testable endpoints in your service for more straightforward performance testing in the future.
I’ve actually tackled a similar challenge before, and it’s definitely possible to combine Gatling with headless browser testing for your use case. While Gatling doesn’t natively support headless browsers, you can integrate it with tools like Selenium or Puppeteer to achieve what you’re after.
In my experience, we used Gatling for load generation and Selenium WebDriver with a headless Chrome setup to interact with the UI. We wrote custom Scala code to bridge Gatling and Selenium, allowing us to simulate user interactions and capture performance metrics.
The tricky part was synchronizing the Gatling scenarios with the browser actions and ensuring proper resource management. We ended up creating a custom protocol in Gatling to handle the browser interactions.
It’s not a straightforward setup, but it worked well for our WebSocket-based application. You’ll need to invest some time in the integration, but it can provide valuable insights into your service’s performance under load, especially for UI-dependent workflows.
Just be mindful of the additional overhead introduced by the headless browsers. You might need beefier machines to generate significant load compared to standard API testing.