issue_comments

Table actions

4 rows where author_association = "MEMBER" and issue = 907715257 sorted by updated_at descending

✎ View and edit SQL

This data as json, CSV (advanced)

Suggested facets: reactions, created_at (date), updated_at (date)

issue 1

  • Split up tests? · 4 ✖

author_association 1

  • MEMBER · 4 ✖
id html_url issue_url node_id user created_at updated_at ▲ author_association body reactions performed_via_github_app issue
854846205 https://github.com/pydata/xarray/issues/5409#issuecomment-854846205 https://api.github.com/repos/pydata/xarray/issues/5409 MDEyOklzc3VlQ29tbWVudDg1NDg0NjIwNQ== TomNicholas 35968931 2021-06-04T16:16:30Z 2021-06-04T21:16:19Z MEMBER

This is kind of a general question whenever we add new features: if I add to the API such that I can access my new computation newfunc via any of da.newfunc(), ds.newfunc() or xr.newfunc(), then should the tests live in test_dataarray.py, test_dataset.py, test_computation.py, all three of them, or make a new file test_newfunc.py? I agree we should move towards the latter, and try to just make test_dataarray.py & test_dataset.py test the core functionality of those objects, and not their extensive method APIs.

 
{
    "total_count": 3,
    "+1": 3,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Split up tests? 907715257
853255253 https://github.com/pydata/xarray/issues/5409#issuecomment-853255253 https://api.github.com/repos/pydata/xarray/issues/5409 MDEyOklzc3VlQ29tbWVudDg1MzI1NTI1Mw== max-sixty 5635139 2021-06-02T17:47:21Z 2021-06-02T17:47:21Z MEMBER

Great, it seems there's some backing for this. What's the best way to start?

I'm happy to do a PR to pull all the rolling tests into test_rolling.py as an example to start. I'm also happy to say any new rolling tests need to go into test_rolling.py, to minimize movement, as suggested above. But maybe that's hard to manage, and it's not obvious that's the policy for new contributors.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Split up tests? 907715257
852687626 https://github.com/pydata/xarray/issues/5409#issuecomment-852687626 https://api.github.com/repos/pydata/xarray/issues/5409 MDEyOklzc3VlQ29tbWVudDg1MjY4NzYyNg== shoyer 1217238 2021-06-02T03:28:34Z 2021-06-02T03:28:34Z MEMBER

Yes, splitting up these giant test files would definitely be a good idea. test_backends.py might be another good candidate.

I don't think there was ever a good reason why they needed be in a single class. unittest works just fine with multiple test classes, too.

 
{
    "total_count": 0,
    "+1": 0,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Split up tests? 907715257
851702677 https://github.com/pydata/xarray/issues/5409#issuecomment-851702677 https://api.github.com/repos/pydata/xarray/issues/5409 MDEyOklzc3VlQ29tbWVudDg1MTcwMjY3Nw== keewis 14808389 2021-05-31T22:21:47Z 2021-05-31T22:21:47Z MEMBER

that sounds like a good idea, and we'll definitely have to do this gradually because PRs with several thousand lines of changes are really difficult to review.

Probably unrelated, but I'd also like to refactor / reorder the tests in test_combine.py.

 
{
    "total_count": 1,
    "+1": 1,
    "-1": 0,
    "laugh": 0,
    "hooray": 0,
    "confused": 0,
    "heart": 0,
    "rocket": 0,
    "eyes": 0
}
   Split up tests? 907715257

Advanced export

JSON shape: default, array, newline-delimited, object

CSV options: 

CREATE TABLE [issue_comments] (
   [html_url] TEXT,
   [issue_url] TEXT,
   [id] INTEGER PRIMARY KEY,
   [node_id] TEXT,
   [user] INTEGER REFERENCES [users]([id]),
   [created_at] TEXT,
   [updated_at] TEXT,
   [author_association] TEXT,
   [body] TEXT,
   [reactions] TEXT,
   [performed_via_github_app] TEXT,
   [issue] INTEGER REFERENCES [issues]([id])
);
CREATE INDEX [idx_issue_comments_issue]
    ON [issue_comments] ([issue]);
CREATE INDEX [idx_issue_comments_user]
    ON [issue_comments] ([user]);