TST/CLN: Consolidate creation of groupby method args
- [ ] closes #xxxx (Replace xxxx with the Github issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [ ] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.

Wasn't sure if it was better to put the helper in `__init__`  or create `common`.
Thanks @rhshadrach lgtm. and no documentation is too much (imo) so that we are more casual contributor friendly. merge when green. > As a rule I do not see changing tests as necessarily a benefit. Parameterizing most definitely so that we can test more for consistency.

> no documentation is too much (imo) so that we are more casual contributor friendly

For me, sometimes one of the difficult parts of doing a PR is just figuring out where a test should go. In the same vein as documentation, I think making tests easier to write would be a way to make pandas more contributor friendly. So I do think cleaning up tests where possible would be a benefit.

In fact, I've spent quite some effort trying to figure out ways to better organize and write groupby tests because of this, but rarely do I find a change that's worth doing. The trouble is there are so many ways to parametrize, and how best to do it really depends on the test:

 - the type of object being grouped - i.e. SeriesGroupBy and DataFrameGroupBy
 - the methods being used (e.g. sum, mean, fillna)
 - the arguments (e.g. `.groupby(axis=0)` and `.groupby(axis=1)`), especially `by`
 - the dtypes of the input (including single vs multiindex, and especially categorical)

Various tests parametrize over one or multiple of these, and many more don't parametrize at all but probably should. I've never been able to find a good way to organize tests for parametrizations, but would strongly feel we should refactor if there was one. Thanks @rhshadrach (failure unrelated).

My 2c: I think test cleanup can be worth it if it's:

1. Test reorganization/renaming such that it's more intuitive to know where to place things
2. Simplifying tests & using more pytest idioms such that debugging a failing test is more direct. 

I think creating a "groupby testing parameterization matrix" of grouping objects x object dtypes x groupby methods x method arguments would be really nice to have running (although maybe redundant with some existing tests), but it would probably be best for it to be a new testing file instead of augmenting what already exists. Thanks @simonjayhawkins and @mroeschke for sharing your thoughts.