Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 98.62%. Comparing base (af42043) to head (a210ccf).
⚠️ Report is 75 commits behind head on master.

@@           Coverage Diff           @@
##           master    #1157   +/-   ##
=======================================
  Coverage   98.62%   98.62%           
=======================================
  Files          27       27           
  Lines        3553     3553           
  Branches      561      561           
=======================================
  Hits         3504     3504           
  Misses         17       17           
  Partials       32       32           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

CodSpeed Performance Report

Merging #1157 will not alter performance

_{Comparing shorten (a210ccf) with master (af42043)}

Summary

✅ 4 untouched benchmarks
🆕 240 new benchmarks
⁉️ 240 (👁 240) dropped benchmarks

Benchmarks breakdown

ℹ️ Only the first 20 benchmarks are displayed. Go to the app to view all benchmarks.

The programming world is full of short names and abbreviations.
We all live with it without any problem.
If the fixture name takes half of the allowed line width -- it is a problem from my perspective.
Python has a long tradition for using shorteners: len() v.s. length(), __init__() v.s. __initializer__(), dict v.s. dictionary.

All these short names are pretty readable and maintainable.

Moreover, I personally found that case_sensitive / case_insensitive pair gives me a higher chance of making a mistake than ci / cs.

@bdraco @Dreamsorcerer guys, please share your opinion on the raised question, do you prefer short abbreviated names in tests or as-long-as-possible ones?

I try to aim to be concise, but unambiguous. It's easy to go too far in either direction. The changes in this PR don't seem to make a significant difference to me, so I don't mind either way (I might err slightly to leaving the current state, just to avoid git blame noise).

I agree with Nick's assessment of difficulties present on devices with insufficient screen estate. That's one of the reasons I tend to insist on short lines.

I also often use shorter identifiers in various UI labels (like GHA).

Shortcuts are sometimes acceptable. Like in cases of commonly known terms/abbreviations (MD is a medical doctor, right? Everybody knows that!).
Weird shortened words are fine in tightly scoped contexts (like in a function), where they can be deducted easily.

In this case, however, other contexts should be taken into account too.

The fixtures already contain one abbreviation (CI for continuous integration, huh? 😉). And that is already somewhat questionable. But at least it matches the actual class names. Adding a chain of abbreviations is definitely not readable. Sure, it might degrade some Æstetics a little bit.

But what about other places where readability counts? We cnt jst strt drppn lttrs bcs o' 1 sngl tbl on gh.

I think this would penalize maintainability long-term at the cost of a short-term satisfaction.

Maybe short fixture names and comprehensive docstrings could provide a good enough compromise?
I'll add docstrings to the PR soon; after Spanish lockout my spare time is very limited :)

The docstrings should always be verbose so that pytest --collect-only --fixtures is useful.

But that doesn't really fix the problem of a series of abbreviations being used in disconnected contexts because it adds mental overhead affecting when consuming the thing. Code is read much more often than it's being written, and for that reason it's important to optimize for the reading experience. The readers aren't just 1–2 people in the inner circle, and I was optimizing for inclusivity rather than creating entry barriers for potential contributors.

I'm in favor of making names shorter where this doesn't compromise readability. py and ext are generally fine. But dropping any context is a no-go because of mental overhead. When I see cs, I know that it's obviously a locale code fore Czech. I might've thought of something like Counter Strike if it was upper case. But any other meanings would never be my first guess, nor second or third even.

We have an agreement for py and ext, it's excellent!
Regarding cs -- we can drop it entirely.
The public API has an implicit assumption that the absent prefix is for case-sensitivity (MultiDict) and that case-insensitive things are coded with a ci prefix: CIMultiDict and CIMultiDictProxy.
ci is backed in our domain already, it is a part of the library's public API and should not cause ambiguity in the library's context.

ci is only fine when followed bymultidict in source code. But pytest test IDs target different contexts and shouldn't use ambiguous contractions.

@webknjaz are you kidding me?
What is the different context?
Multidict has literally 2,5 classes and one function, that's it.
Where is the space for different mental contexts? Where is the space for ambiguity? The domain is so tiny that it can fit in any brain easily.
But long names don't fit on the screen, especially for mobile devices.
This is the point, nothing else.

We have a total of 58 contributors over the past 10 years, including the project admins. 95% of contributors made fewer than 10 commits throughout the entire history. I don't think anybody will suffer after the change.