Add hypothesis property tests

[dcherian]

After mamba install hypothesis

Use

python -m pytest --capture=no --hypothesis-verbosity=verbose test_properties.py

to see all the things it tries.

This was a quick attempt at a property test.

The other thing you can do is a "Stateful" test (e.g. https://github.com/pydata/xarray/blob/main/properties/test_index_manipulation.py)

which runs an arbitrary sequence of manipulations (e.g. add array, rename, move, delete, modify array, copy), and checks for consistency at each point.

cc @Zac-HD

TODO:

• Add unit tests and/or doctests in docstrings
• Add docstrings and API docs for any new/modified user-facing classes and functions
• New/modified features documented in docs/tutorial.rst
• Changes documented in docs/release.rst
• GitHub Actions have all passed
• Test coverage is 100% (Codecov passes)

[pep8speaks]

Hello @dcherian! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file tests/test_properties.py:

Line 5:1: E402 module level import not at top of file
Line 6:1: E402 module level import not at top of file
Line 8:1: E402 module level import not at top of file
Line 9:1: E402 module level import not at top of file
Line 10:1: E402 module level import not at top of file
Line 11:1: E402 module level import not at top of file
Line 12:1: E402 module level import not at top of file
Line 14:1: E402 module level import not at top of file
Line 15:1: E402 module level import not at top of file
Line 17:1: E266 too many leading '#' for block comment

Comment last updated at 2024-04-05 17:47:12 UTC

[dcherian]

totally not obvious!

[dcherian]

Some input needed:

1. Should this be a separate action or folded in to the existing actions? I lean former. It's fast now (47s) but it could get slower in the future.
2. There's more to make strategies.py actually useful as public API but I'd like to punt that to the future.
3. I'll make comments where I'd like a careful review.

[dcherian]

Can this mess be cleaned up?

[dcherian]

This looks like a real failure:

 E           AssertionError: 
E           Arrays are not equal
E           
E           Mismatched elements: 1 / 1 (100%)
E           Max absolute difference: 1
E           Max relative difference: inf
E            x: array([1], dtype=int8)
E            y: array([0], dtype=int8)

Apparently it is not roundtripping np.array([1], dtype=np.int8) @d-v-b are you able to take a look?

[d-v-b]

This looks like a real failure:

 E           AssertionError: 
E           Arrays are not equal
E           
E           Mismatched elements: 1 / 1 (100%)
E           Max absolute difference: 1
E           Max relative difference: inf
E            x: array([1], dtype=int8)
E            y: array([0], dtype=int8)

Apparently it is not roundtripping np.array([1], dtype=np.int8) @d-v-b are you able to take a look?

definitely! Given that I know nothing about hypothesis, how can I replicate this failure locally?

[dcherian]

This may be user error. It's sensitive to the store.close()

import zarr
from zarr.array import Array
from zarr.group import Group
from zarr.store import MemoryStore
import numpy as np

store = MemoryStore(mode="w")
root = Group.create(store)
nparray = np.array([1], dtype=np.int8)
    
a = root.create_array(
    "/0/0",
    shape=nparray.shape,
    chunks=(1,),
    dtype=nparray.dtype.str,
    attributes={},
    # compressor=compressor,  # TODO: FIXME
    fill_value=nparray.dtype.type(0),
)
a[:] = nparray
print(a[:]) # [1]
store.close()
print(a[:]) # [0]

[d-v-b]

I can replicate this locally. store.close is quite minimal so I think our problem lies elsewhere. I will investigate.

[dcherian]

pre-commit.ci autofix