How would I trust the correctness of this library without any testing?

[Profpatsch]

main :: IO ()
main = putStrLn "Test suite not yet implemented"

It’s very nice that somebody invested the effort to implement http2, but having no testing in place at all makes me wonder what the implementation strategy was and how regressions are dealt with (which undoubtedly happen a lot when implementing such a large protocol).

[lucasdicioccio]

Hi @Profpatsch

Thanks for showing interest in http2-client. That said, I have a few problems with your bug report.

First, I think you should be the only one to judge whether or not to trust a software package for yourself. The question of trust is deep and answering this question is, I believe, a journey on your own. I cannot in good faith answer "trust me" as I encourage fellow engineers to make data-based decisions. If your criteria for trusting a library is "has a unit test in the test/ dir" then I'm sorry http2-client is not good enough yet and we'll work toward this in the future. Somehow, I commend the fact-based approach. In the meantime, if I can convince you to try http2-client and if your procedure to build trust with the package involves building some test code or infrastucture that you can share with the larger community, then I encourage you to contribute back -- even if you do not end up being an http2-client user in the future.

Second, I think it's unfair to say the package is provided "without any testing"; https://github.com/lucasdicioccio/http2-client#help-and-examples explains that there exists an example binary --which I personally use to validate my changes against a warp-tls application and some webpages that support HTTP2-push (e.g., cloudflare's homepage, https://http2.golang.org/serverpush). If you don't think this is automated enough, d47d3d2 introduced a way to run this example application against a number of famous websites (not all of them support HTT2). I haven't had time to automate further the creation of reports (nor prune HTTP1-only domains from the list of famous websites). In general it's not a good etiquette to use third party sites as "test targets" and the example binary already makes it too easy to inadvertently-DoS a website. Hence, I won't be putting this script in a way where it will run unmonitored such as CI pipelines of people who vendor my code. Obviously, contributions are welcome.

Third, you are not coming with any idea on how to test a protocol implementation with tests that meaningfully prevent regressions. Hence, even if I write some tests I would not credit this bug report (as it is written now) a mention in the commit messages. I did my research and so far I've found an http2-client that allows to test server implementations but not the other way around. Hence, I'm iterating the goofy way (cf. previous point), validating primarily against warp because it's the reference server that costs me the least to "tweak". This methodology is archaic but I could find three bugs in warp's HTTP2 implementation (I've fixed two of them). I feel like only one of the three bugs would have been an easy candidate for unit-tests (and it was a mundane-as-hell filter, the two other ones are race conditions). I reckon that a good test suites would be awesome but my experience with protocols pushes me to think writing a good test suites is really hard (https://github.com/netty/netty/tree/4.1/codec-http2/src/test/java/io/netty/handler/codec/http2 gives an idea of the amount of work). Hence, at this point of the development if you want me to write unit-tests it will be your job to convince me this is the best use of my effort budget. The closest issue I have are #5 (to allow to encode test scenarios) and #9 (which comes naturally with this). In my Reddit announce I've also said I'm welcoming contribution to the code but I'm also looking forward to build some automation to validate against implementations found "in the wild". Ideas are welcome too!

Sorry if this is not the answer you expected but "it's open source"(tm).