fix: make tests more lenient with changing serialization of timestamps

[fuchsi-huber]

Pull request

Please confirm that this pull request has done the following:

• Tests added
• Documentation added (where applicable)
• Description in a {pr}.thing.md file in the directory changelog added - see changelog/README.md for details

Description

A few tests failed due to inconsistent precision of timestamps (6 vs. 9 positions after the seconds). Reduced the checks in the tests to the essential part that ensures that the correct failure branch was taken.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (main@d373f99). Learn more about missing BASE report.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #382   +/-   ##
=======================================
  Coverage        ?   97.29%           
=======================================
  Files           ?       54           
  Lines           ?     5361           
  Branches        ?        0           
=======================================
  Hits            ?     5216           
  Misses          ?      145           
  Partials        ?        0           

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

[mikapfl]

Hmm, that is a case which makes the example significantly worse to read for a human, right? Knowing that the value which already exists is MEX and not confusingly ARG or so is actually quite helpful.

[fuchsi-huber]

True, but then we need to change either the generation of the ValueError (to print __str__ instead of __repr__) or the example to not rely on the exception. The shown value is 'MEX in older versions of numpy and np.str_('MEX') in newer versions

[fuchsi-huber]

A similar problem arises from the DataArray serialization. the expected <Quantity([0.4 0.9 1.7 4.8 3.2 9.1], 'hertz')> is actually Quantity(array([0.4, 0.9, 1.7, 4.8, 3.2, 9.1]), "hertz") in the development xarray versions... I don't think we can maintain this doctest across so many different library versions without reducing the output in the documentation to generics like ...Quantity...hertz... which are really hard to parse for humans. A couple of options I see:

1. as we talked about: remove the examples from the documentation, add them as unit-tests (or similar) instead and reference those tests in the docs
2. don't check output in the doctests, only that the provided code actually runs and throws exceptions when it is supposed to (which is honestly what we would also do if they are unit tests instead?)
3. restrict the doctests to a single test environment and update the expected output from time to time to match the output in that single test environment

[fuchsi-huber]

I have ignored the exception detail for the mentioned examples and fixed the still failing tests by making them a bit more robust. I guess we have to make these examples not rely on the repr so much in the future.

For now this should pass all tests - though it probably is still not super robust

[mikapfl]

Yeah, using str() instead of repr() in the ValueError is sensible, I think, in this specific instance. But more generally, I think we might drop doctests. A pity, but not feasible given how much work it creates.