html_url,issue_url,id,node_id,user,created_at,updated_at,author_association,body,reactions,performed_via_github_app,issue
https://github.com/pydata/xarray/pull/1972#issuecomment-373954379,https://api.github.com/repos/pydata/xarray/issues/1972,373954379,MDEyOklzc3VlQ29tbWVudDM3Mzk1NDM3OQ==,1217238,2018-03-17T21:35:52Z,2018-03-17T21:36:37Z,MEMBER,"> blockers to merging this as-is?

This looks pretty good to me in its current state. I would say we should merge it now and iterate in future PRs.

> other APIs you think it would be reasonably easy to write property tests for? Here's a nice list of properties to test 😄

Almost anywhere where we currently make heavy use of `parametrize` would be a good candidate. Some other possibilities:

- Consistency with pandas for groupby/rolling aggregations.
- Roundtrip writing/reading data to netCDF. There are a couple of known exceptions (e.g., dtypes not supported by netCDF and MultiIndex) but otherwise every xarray object should be serializable to netCDF and back without data loss.
- Roundtrip to/from pandas Series/DataFrame with `to_series()`/`to_dataframe()`/`to_xarray()`.
- Indexing consistency tests for backends: all indexing operations should be supported consistently on data accessed from any backend.
- NumPy vs Dask: any operation on dask arrays should be consistent with the operation on numpy arrays (e.g., `f(xarray_obj.chunk()).compute() == f(xarray_obj)`).
- Indexing followed by `xarray.concat`: should get back the same result.
- Binary arithmetic on xarray objects with Python operators  (`+`, `-`, etc) and NumPy ufuncs (`np.add`, `np.subtract`, etc).","{""total_count"": 1, ""+1"": 1, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,303103716
https://github.com/pydata/xarray/pull/1972#issuecomment-371672811,https://api.github.com/repos/pydata/xarray/issues/1972,371672811,MDEyOklzc3VlQ29tbWVudDM3MTY3MjgxMQ==,1217238,2018-03-09T00:31:07Z,2018-03-09T00:31:07Z,MEMBER,"One thing that comes to mind is organization... would it make sense to put this alongside the current xarray tests, e.g., have `xarray/tests/unit` and `xarray/tests/property`?

I guess one downside of this would be that it could change how we need to invoke py.test by default, if we don't want to trigger all the property based tests.","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,303103716
https://github.com/pydata/xarray/pull/1972#issuecomment-371593519,https://api.github.com/repos/pydata/xarray/issues/1972,371593519,MDEyOklzc3VlQ29tbWVudDM3MTU5MzUxOQ==,1217238,2018-03-08T19:17:48Z,2018-03-08T19:17:48Z,MEMBER,"This looks like a great start to me -- thank you!

It's impressive that it's possible to break every plotting type with matplotlib :).","{""total_count"": 0, ""+1"": 0, ""-1"": 0, ""laugh"": 0, ""hooray"": 0, ""confused"": 0, ""heart"": 0, ""rocket"": 0, ""eyes"": 0}",,303103716