TST: method-specific files for droplevel

[jbrockmendel]

No description provided.

[WillAyd]

Maybe missed on a previous PR but is the plan to do a separate module for every method? I don’t think its current location is necessarily problematic so just curious of the motivation for this

[jbrockmendel]

but is the plan to do a separate module for every method?

Not quite. Some criteria that make a method a candidate for this treatment:

• is X a top-level method that isnt relied on by any/many other methods?
  • e.g. TST: implement test_first #32274 I could easily go months at a time without remembering that first or last exist
• is it easy to grep to determine that we have collected all tests for X?
  • e.g. first_valid_index
• is it not-obvious where tests for X would go?
  • e.g. DataFrame.insert tests could go in a number of places based on filenames in tests/frame/
• does X not fit into one of the better-defined buckets of arithmetic/indexing/reductions/cumulative?
• are the tests for X candidates to be shared between Series/DataFrame
  • e.g. droplevel, to_timestamp, to_period, see also discussion in TST: implement test_first #32274.
• is X a method that exists on multiple classes where we can't necessary share tests, but it is helpful to have a parallel test structure
  • e.g. searchsorted

Hope this helps.

[jreback]

thanks @jbrockmendel

@WillAyd as a general rule having more fine-grained test files is a goal.