Add test coverage for stac_api_io.py error handling

[nlebovits]

Related Issue(s):

• Increase test coverage #590

Description:

• Test decode error in request() method
• Test write to URL error in write_text_to_href()
• Test unknown STAC object type error in stac_object_from_dict()

PR Checklist:

• Code is formatted
• Tests pass
• Changes are added to CHANGELOG.md

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.82%. Comparing base (21435b0) to head (b47096b).
⚠️ Report is 149 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #835      +/-   ##
==========================================
+ Coverage   93.43%   94.82%   +1.38%     
==========================================
  Files          13       15       +2     
  Lines         990     1217     +227     
==========================================
+ Hits          925     1154     +229     
+ Misses         65       63       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[gadomski]

Could we just modify the real_stac_data with a bogus type attribute, instead of mocking the functions?

[nlebovits]

@gadomski Back from travel and picking this up. identify_stac_object_type in pystac will raise a STACTypeError if the object type is not one of catalog, collection, or item (https://pystac.readthedocs.io/en/v1.12.2/_modules/pystac/serialization/identify.html#identify_stac_object). So I don't think the ValueError at line 290 in stac_api_io.py would ever be triggered, since pystac is catching type errors before then. I was mocking to get around that error, but should have dug deeper.

I'd suggest removing my test and marking the ValueError at line 290 with something like # pragma: no cover, since pystac should guarantee that we only get valid types. Alternatively, we could remove both. Do you have a preference?