Design: streamline communication with browser

[SvenMarcus]

Testing communication with browser processes is a pain.
Since the proxy module still uses HTTP requests directly, we need to run an actual server process in the background to simulate a broadway process.
That means in tests we cannot use generalized navigation functions that go through the entire process of opening the browser with in-memory test doubles (e.g. /workspaces/<workspace>/ping always sends an HTTP request)

For WebSocket communication, we have already introduced an open_channel() method in the OcrdBrowser protocol. We can use a similar approach for HTTP requests. This would also make communication with browser processes more consistent.

classDiagram
    OcrdBrowser --> BrowserClient
    BrowserClient --> Channel
    
    class OcrdBrowser {
        +client(): BrowserClient
        +start()
        +stop()
    }

    class BrowserClient {
        +open_channel(): Channel
        +request(resource: str): Response
    }

    class Channel {
        +send_bytes(data: bytes)
        +receive_bytes(): bytes
    }

Loading

[markusweigelt]

Is it so reasonable to design the application according to the tests if there is no direct use besides the tests? What about mocking?

[SvenMarcus]

What I'm doing is essentially mocking the manual way. I'm avoiding monkey patching in application logic as this couples us tightly to certain method calls.
Essentially, the OcrdBrowser is another application whose behavior we cannot control from the monitor. Therefore, we want to encapsulate implementation details concerning the browser to keep the monitor application easily testable.