Reader Question
A reader sent me this question about his own experiences debugging his code (shared with permission):
One of the bugs I find the hardest to solve is the simple 404 error. It's so generic, yet the solution is rarely ever the same it seems. Do you have any resources on steps to take or things to consider when troubleshooting a 404?
This question perfectly illustrates yesterday's point about boundaries. The reader points out that "the solution is rarely ever the same", and that is because the 404 is not the bug. The 404 is a symptom of the bug. And lucky for us, this particular symptom is manifesting right at the boundary between the client and server.
If we know the route that we expect to be called here, we can inspect the HTTP request and see if that is in fact what our client is requesting. No theories yet, just evaluating correctness.
For example, let's say we're trying to load a list of all the articles written by a particular user. We're getting a 404 when the client tries to fetch them. We know that the endpoint for getting the articles is /users/:userId/articles, and we know that the user's id is 456. Therefore, we expect to see a GET request to /users/456/articles. If we open the network inspector and see that instead it's making a request to /users/undefined/articles, we know that something is wrong in the client logic that creates the request.
Remember that we could still have a problem in with the server! It's entirely possible that your server also doesn't know what to do with the correct request to /users/456/articles, but we've identified that something is definitely wrong before we get to that point. Starting at the boundary allows us to disregard the server for the time being and just focus on getting the client to behave.
Now suppose you find and fix the issue in the client (I'll cover that in more detail on Monday) and you verify that it's sending the correct request to the correct route. If you're still getting a 404, you can start looking at why the server won't respond correctly to the route. If you hadn't looked at the boundary and you only articulated the bug as "I get a 404", you would have no idea that this is in fact two separate issues. You might have applied a fix to one side of the boundary, still seen a 404, and concluded that your fix didn't have any effect.
When you test at the boundaries, you're testing discrete, known behaviors of defined systems instead of giant, amorphous blobs of code.
More on Monday.
Next Up:
Time to Hypothesize
Previously:
Good Boundaries Make For Easier Debugging
