TST: method-specific files for droplevel
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 > 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. #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 #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. thanks @jbrockmendel 

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