Currently, the HTTP proxy only has tests for validations. Request handling and manipulation is tested, albeit at the handler level. This is fine for these request tests, but as more responsibilities are added to the proxy, such as initializing and reporting metrics (#312), these gaps start to show up.
The main blocker to add tests to the HTTP proxy is that, on its Start method, it sets up a listener according to an address supplied through configuration:
Unfortunately, this does not allow parallel tests to be created as the port needs to be chosen in advance, and it is not possible to pick a port that is guaranteed to be unused. The GRPC Proxy is tested, and works around this problem by listening on a unix socket on a randomly generated path. This is, however, not possible to do for HTTP servers.
A possible solution for this could be to move initialization of the listener outside of the HTTP proxy, pass that listener in the constructor, and replace p.srv.ListenAndServe with p.srv.Serve(p.listener) with p.listener being this new listener. This, however, is not free from drawbacks, as it would move the responsibility of creating a listener upwards to the command, which already has a fair amount of responsibilities.
Currently, the HTTP proxy only has tests for validations. Request handling and manipulation is tested, albeit at the handler level. This is fine for these request tests, but as more responsibilities are added to the proxy, such as initializing and reporting metrics (#312), these gaps start to show up.
The main blocker to add tests to the HTTP proxy is that, on its
Startmethod, it sets up a listener according to an address supplied through configuration:https://github.com/grafana/xk6-disruptor/blob/ea0c557dab218a3aa5b0ed24779480c5d7a7743e/pkg/agent/protocol/http/proxy.go#L182-L187
Unfortunately, this does not allow parallel tests to be created as the port needs to be chosen in advance, and it is not possible to pick a port that is guaranteed to be unused. The GRPC Proxy is tested, and works around this problem by listening on a unix socket on a randomly generated path. This is, however, not possible to do for HTTP servers.
A possible solution for this could be to move initialization of the listener outside of the HTTP proxy, pass that listener in the constructor, and replace
p.srv.ListenAndServewithp.srv.Serve(p.listener)withp.listenerbeing this new listener. This, however, is not free from drawbacks, as it would move the responsibility of creating a listener upwards to the command, which already has a fair amount of responsibilities.