Improve test coverage for storage classes#2693
Conversation
|
Labeler is fixed now on main |
dstansby
left a comment
There was a problem hiding this comment.
Thanks for all the changelog updates! I added a couple of minor suggestions. I think https://github.com/zarr-developers/zarr-python/pull/2693/files#r1913045841 is an outstanding question that still needs resolving too?
Other than that, is this ready to go from your point of view @maxrjones?
Co-authored-by: David Stansby <dstansby@gmail.com>
Thanks! Yes, I believe this is ready to go aside from the open questions about |
jhamman
left a comment
There was a problem hiding this comment.
Thanks so much for doing this @maxrjones. This is a great improvement AND exposes some rough edges in our store API. The good news there is that I think there are some relatively easy improvements we can make to clean up those rough edges.
This PR improves the test coverage for the various storage classes. While testing the storage classes, I fixed a few issues:
open()forLoggingStore_is_openproperty and setter forWrapperStorestdoutrather thanstderras the default stream forLoggingStoreZipStoreis open before getting or setting any valuesLoggingStoreandWrapperStoresuch that the types much be equal. This is an opinionated change. For example, previously a LocalStore and LoggingStore instance could be evaluated as equal, whereas now they are distinct.Here's the change in coverage:
src/zarr/storage/memory.pycoverage is low because it includes the GPUStore and I don't have a test environment with cuda. I'm opening this PR now even though it's not at 100% coverage because I don't expect to have much time to work on it during the week and would rather the PR not get stale if the team has time for a review.The set partial values methods are addressed separately because they require discussion (xref #2688).