Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Export wstest.Pipe for in memory tests #197

Closed
nhooyr opened this issue Feb 26, 2020 · 7 comments
Closed

Export wstest.Pipe for in memory tests #197

nhooyr opened this issue Feb 26, 2020 · 7 comments

Comments

@nhooyr
Copy link
Owner

nhooyr commented Feb 26, 2020

Would be really cool to have an in memory WebSocket implementation for tests versus starting a net/http test server every test.

@nhooyr
Copy link
Owner Author

nhooyr commented Feb 26, 2020

Not sure if this is a good idea anymore with #199 🤔

@nhooyr nhooyr added this to the v1.9.0 milestone Feb 26, 2020
@nhooyr
Copy link
Owner Author

nhooyr commented Feb 26, 2020

Any thoughts @coadler?

@nhooyr
Copy link
Owner Author

nhooyr commented Feb 26, 2020

Looks like this:

func Pipe(dialOpts *websocket.DialOptions, acceptOpts *websocket.AcceptOptions) (clientConn, serverConn *websocket.Conn) {

@nhooyr
Copy link
Owner Author

nhooyr commented Feb 26, 2020

// Pipe is used to create an in memory connection
// between two websockets analogous to net.Pipe.
func Pipe(dialOpts *websocket.DialOptions, acceptOpts *websocket.AcceptOptions) (clientConn, serverConn *websocket.Conn) {
    // ...
}

@nhooyr
Copy link
Owner Author

nhooyr commented Feb 26, 2020

If I were to export it, I'd change the signature to:

func Pipe() (http.RoundTripper, http.ResponseWriter)

Any upgrade requests sent on the round tripper would wait for the given response writer to hijack and accept the WebSocket or otherwise respond.

@nhooyr
Copy link
Owner Author

nhooyr commented Apr 14, 2020

Not sure if this is a good idea anymore as httptest makes it so easy already and I don't think there are enough scenarios where you want in memory web sockets vs abstracting away the transport and passing around messages directly. The only good scenario I can really think of is writing tests for the library which is why it exists.

@nhooyr nhooyr removed this from the v1.9.0 milestone Apr 14, 2020
@nhooyr
Copy link
Owner Author

nhooyr commented Apr 14, 2020

Yea, going to close this for now. Only real problem is ensuring graceful shutdown in tests for which #209 is open.

@nhooyr nhooyr closed this as completed Apr 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant