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

public interface for regression tests? #136

Open
clarkevans opened this issue Dec 29, 2020 · 4 comments
Open

public interface for regression tests? #136

clarkevans opened this issue Dec 29, 2020 · 4 comments

Comments

@clarkevans
Copy link

Currently, Mux doesn't export http_handler in its public interface, yet, something like it is required to build regression tests that don't open a socket. Indeed, opening a socket isn't really required to test Mux... you just send a Request and get a Response object. Here is a rough stab at a trivial wrapper to make get and post requests where one could type get("/") to print the given response to stdout.

@app APP = ...
loopback(req::Request) = 
  read(IOBuffer(HTTP.handle(Mux.http_handler(APP), req).body), String)
wget(url) = println(loopback(HTTP.Request("GET", url)))
post(url) = println(loopback(HTTP.Request("POST", url)))

Something similar might be nice to include so that application developers could test their interfaces w/o having a webserver active. Generally, we might wish to also consider updating regression tests in this project to use a similar method. There's no real need to test most of the functionality via sockets. At this level in the stack what's matter is functionality via Request/Response.

@cmcaine
Copy link
Collaborator

cmcaine commented Dec 29, 2020

Yes, I think we should at least document how to test without opening sockets.

I don't think this is only useful for regression testing.

All you need to do is response = yourappname.warez(HTTP.Request(blah)) but the warez field is private at the mo. (The http_handler stuff doesn't do all that much, really).

I don't know what the public interface should be, opinions welcome or I'll just experiment :)

The normal way to get a string from a vector of bytes would be String(bytes) or String(take!(bytes)), btw. No need to wrap in an IOBuffer. Or you can copy(bytes) if you don't want it mutated.

@clarkevans
Copy link
Author

clarkevans commented Dec 29, 2020

Perhaps make Mux.App callable?

 (app::App)(req::Request)::Response = app.warez(req)
 (app::App)(method, location) = app(Request(method, location))

Oh, I dislike http_handler magic with regard to converting a Dict to a Response object anyway. That might be a good candidate for removal.

@cmcaine
Copy link
Collaborator

cmcaine commented Dec 29, 2020

I talked about removing mk_response in another PR and might do that.

Making App callable is what I was thinking of doing, too, but I haven't thought it all through yet :)

I'd probably just define this if I did:

(app::App)(x) = app.warex(x)

I don't think it's our responsibility to provide easier ways of creating HTTP request objects, or if we did do that, it can be in a Mux.Request function or something?

@clarkevans
Copy link
Author

I think mk_response is rather specialized and could be implemented in user code if someone wanted, so yea, I support removing it as #129 mentions.

Making the definition, (app::App)(x) = app.warex(x) seems obvious/useful.

It's not Mux responsibility to create HTTP request objects. There is one bit of code that checks if an object is showable via "text/html, setting "Content-Type" appropriately -- that might be useful to keep.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants