At the 2022 edition of GopherCon Brasil, I had the pleasure of speaking about the Fuzz Test. It was cool because during the lecture and in the event halls, they asked several questions that I hadn’t asked about this Go feature yet.
If you are not yet familiar with this type of test, I invite you to read a post we published on the blog (link to the post), where we explain the subject better.
What I’m going to deal with in this post is the result of the questions asked at the event, plus a link that Ricardo Maricato sent me.
To see one of the ways to implement Fuzz Testing for HTTP requests, let’s implement an endpoint for validating a person’s data.
Let’s start by creating a struct with a validation method and some variables to store any validation errors we might get.
Now, let’s implement the handler that will decode the payload and perform the necessary validations.
Lastly, we need to implement our main function. The complete file will look like this:
That’s great! Now that we have our endpoint implemented, let’s start writing our Fuzz Test function.
We can think of our function in five blocks:
-> Create some test cases;
-> Add the test cases as Seed to the fuzz;
-> Map known errors;
-> Start a test server;
-> A function that will receive the generated inputs.
Inside the function that will receive the inputs, we will perform a POST with the input generated and then validate if the status code is different from 200.
If it is not 200, we need to validate whether the error returned was one of the errors we mapped or something we did not expect.
The complete file will look like this:
By running our test with the command go test -fuzz . -v got the following result:
Taking a look at the testdata/fuzz/FuzzValidate folder, we can verify which was the request input that failed.
go test fuzz v1
[]byte(“0”)
Hmmm… I really wasn’t expecting an out-of-format input. To solve this problem and make our code testable, let’s add a new error variable, and modify the status and error message when the payload is not in the expected format.
We need to add this new error to our list of known test function errors.
By rerunning go test -fuzz . -v for more than 1 minute, I didn’t get any more errors.
This type of test we write will help us validate unexpected payloads. After this scenario, we can write another type of fuzz test to generate unexpected inputs in an expected payload.
However, not to get too long, this other mode will be for another post.
In the meantime, if you want to learn more about testing in Go, check out our “Testing and Benchmarking” course.
Also, leave your doubts in the comments.
See you next time.
*The content of this article is the author’s responsibility and does not necessarily reflect the opinion of iMasters.
Leave a comment