Is there a way to test using Gatling but do it through a headless browser context?

Question

So I have a scenario where I have a service which I'm trying to create automated Gatling performance tests for, issue being that it does not expose any REST endpoints for me to test against. The way the service works is it uses websockets to poll data from various sources and displays it in the services UI. Would it be feasible to create some headless browser context where we take a screenshot of the service UI, then somehow in Gatling use that to do performance tests?

The way I understand Gatling is that we need some endpoints/sockets to use for the test scenarios but the service unfortunately does not expose much for me to go down that route, so I'm asking if it's reasonable and possible to try and combine some headless browser to allow Galting to use it as a means for creating calls which then it can test the performance of.

Answer 1

Gatling does support WebSockets so you don't need a browser, no matter headless or normal.

Although it's possible to come up with your own protocol handler and integrate Gatling with Selenium or other browser automation framework you won't get valid good results, see Selenium documentation on it:

Performance testing using Selenium and WebDriver is generally not advised. Not because it is incapable, but because it is not optimised for the job and you are unlikely to get good results.

Similar information can be found in Gatling and Selenium thread

In case you still want to use real browser it might be easier to consider switching to Apache JMeter which can be integrated with Selenium via WebDriver Sampler (can be installed using JMeter Plugins Manager) however I would rather suggest using your browser developer tools to capture WebSocket calls and implement them in Gatling (or whatever load testing tool supporting WebSockets)

Answer 2

Gatling is only for backend testing with all of its protocols, such as HTTP, WebSocket, etc.

There cannot be any UI interaction, and there's a reason. You can consider using a browser in proper load testing as costly computing, and it adds overhead. To create a high load, you probably have to set up dozens and hundreds of instances with browsers instead of one instance with only requests on the backend. So, the proper way is to just replicate UI usage with backend calls.