More descriptive Mock API errors, take 2

[spatten]

Overview

Provide an overview of this change. Describe the intent of this change, and how it implements that intent.

Example: This PR accomplishes X by doing Y.

Acceptance criteria

If this PR is successful, what impact does it have on the user experience?

Example: When users do X, Y should now happen.

Testing plan

How did you validate that this PR works? What literal steps did you take when manually checking that your code works?

Example:

1. Set up test case X.
2. Run command Y. Make sure Z happens.

This section should list concrete steps that a reviewer can sanity check and repeat on their own machine (and provide any needed test cases).

Risks

Highlight any areas that you're unsure of, want feedback on, or want reviewers to pay particular attention to.

Example: I'm not sure I did X correctly, can reviewers please double-check that for me?

References

Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.

Example:

• ANE-123: Implement X.

Checklist

• [ ] I added tests for this PR's change (or explained in the PR description why tests don't make sense).
• [ ] If this PR introduced a user-visible change, I added documentation into docs/.
• [ ] If this change is externally visible, I updated Changelog.md. If this PR did not mark a release, I added my changes into an # Unreleased section at the top.
• [ ] If I made changes to .fossa.yml or fossa-deps.{json.yml}, I updated docs/references/files/*.schema.json. You may also need to update these if you have added/removed new dependency type (e.g. pip) or analysis target type (e.g. poetry).

[periodic]

I was thinking something like this: https://github.com/fossas/fossa-cli/blob/05ad31f375ea3a75b48bef56be00acef16deee87/test/Test/MockApi.hs

Though printing the error is still a bit awkward.