REF: .dot tests
State: closed

Fully parametrized over Series/DataFrame

Labels:
name: Testing
description: pandas testing functions or related to the test suite

Comments:
from the docs "Going forward, we are moving to a more functional style using the pytest framework, which offers a richer testing framework that will facilitate testing and developing. Thus, instead of writing test classes, we will write test functions like this:"

can you refactor to eliminate the base class.
> from the docs "Going forward, we are moving to a more functional style using the pytest framework, which offers a richer testing framework that will facilitate testing and developing. Thus, instead of writing test classes, we will write test functions like this:"
> 
> can you refactor to eliminate the base class.

we don't want to make changes like this generally when moving, and to be honest the docs are misleading / wrong here. We *do* need classes to namespace things.
> We _do_ need classes to namespace things.

I'm OK with classes for that purpose, but in other modules we have been rmoving base classes, not adding them.
> > We _do_ need classes to namespace things.
> 
> I'm OK with classes for that purpose, but in other modules we have been rmoving base classes, not adding them.

right, I wouldn't change the structure generally (meaning removing just for the sake of removing); i think we might have been doing that in the past.
> i think we might have been doing that in the past.

yeah, in some cases, having the classes is an advantage since it allows decorating the class. (if I recall, you weren't keen on the syntax required to do the same for a module with pytest, i.e. setting module globals)
@simonjayhawkins can you give an example of what your preferred pattern would look like?  the only thing that comes to mind is something like:

```
@pytest.fixture(params=[Series, DataFrame])
def obj(request):
    if request.param is Series:
          return what_the_series_class_fixture_has_now
    else:
          return what_the_frame_class_fixture_has_now
```

which i dont find to be an improvement over class-based implementation
> which i dont find to be an improvement over class-based implementation

that's subjective, and OK.

but we've been moving away from the class based tests (with the exception of extension arrays which are used downstream)

so the concern here is consistency. and fixtures and parameterisation of tests has been the way we have been moving. (rightly or wrongly)

maybe for this PR, you could just move for now to collect the tests and refactor in a follow up.
> maybe for this PR, you could just move for now to collect the tests and refactor in a follow up.

if the end result is going to be "this needs another refactor" either way, aren't we better off with the version where the non-trivial work of sharing the tests is already done?
@jreback wrote "we don't want to make changes like this generally when moving" https://github.com/pandas-dev/pandas/pull/33214#issuecomment-607805583 

so that's the reason i suggested that a straight move be done first.

> aren't we better off with the version where the non-trivial work of sharing the tests is already done?

inherited tests is a valid approach but not something we've been doing (except extension array tests). if we do this we should have a discussion about this and update the guidance first.

can you rebase. also we should clarify when / how to use class based fixtures.