Testing

[SergioBenitez]

The library seems to be devoid of any meaningful testing. What is the testing story? How confident are you that the library works?

[JuanPotato]

https://github.com/abonander/multipart/blob/master/src/local_test.rs

I'd say he's pretty confident

[abonander]

src/local_test.rs is an integration test where the client-side "sends" a request to the server-side via an in-memory buffer, and then checks that it parses all fields correctly. It also randomizes the size of reads, which has helped find bugs in boundary parsing. The problem with testing is that a lot of bugs have arisen from unpredictabilities in network transports, chunking, etc., and are very difficult to reproduce locally. See the lengthy back-and-forth in #51, which I thought I "fixed" several times.

If you have some ideas for additional tests to add, I'd love to hear them.

[SergioBenitez]

@JuanPotato We must have different definitions of confident.

@abonander #51 is exactly what prompted this issue. I'm not sure what you mean by "unpredictabilities in network transports, chunking". These things should be handled at a level below your library. Can you expand on what you mean?

When looking at testing, I expect to see many many real world inputs and expected outputs, especially "strange" ones and edge cases. Fuzzing is a great addition, too.

[abonander]

Everything takes time to implement, and my focus is constantly shifting and I also have bills to pay. For the most part, it's just me maintaining this crate. There's not a whole lot of novelty to draw in contributors.

The common problem is a read stopping in the middle of the boundary, it took me a while to get BoundaryReader to handle that case properly. I couldn't reproduce the problem locally because my tests were previously 100% deterministic.

[abonander]

I've started fuzzing. It has been pretty helpful but also a bit tedious. I've been able to tease out a few different infinite-looping bugs so far. It seems to have generated a large corpus of test inputs, it'll take a while to sift through those and see what errors they actually cause.

Addendum: I guess a new corpus entry doesn't necessarily mean an associated crash. In fact, it doesn't appear that any crashes have cropped up at all. The default timeout (20 minutes!) was too long to efficiently detect infinite loops (an individual test run shouldn't be longer than a few seconds) so I've set it down to 60 seconds.