🧪 Integrate Hypothesis in tests

[webknjaz]

What do these changes do?

$sbj

Are there changes in behavior for the user?

Nah

Related issue number

Nope

Checklist

• I think the code is well written
• Unit tests for the changes exist
• Documentation reflects the changes
• Add a new news fragment into the CHANGES folder
  • name it <issue_id>.<type> (e.g. 588.bugfix)
  • if you don't have an issue_id change it to the pr id after creating the PR
  • ensure type is one of the following:
    • .feature: Signifying a new feature.
    • .bugfix: Signifying a bug fix.
    • .doc: Signifying a documentation improvement.
    • .removal: Signifying a deprecation or removal of public API.
    • .misc: A ticket has been closed, but it is not of interest to users.
  • Make sure to use full sentences with correct case and punctuation, for example: Fix issue with non-ascii contents in doctest text files.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 95.62%. Comparing base (755ba9c) to head (b5a3d89).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #860      +/-   ##
==========================================
+ Coverage   95.57%   95.62%   +0.05%     
==========================================
  Files          30       30              
  Lines        4924     4981      +57     
  Branches      447      464      +17     
==========================================
+ Hits         4706     4763      +57     
  Misses        192      192              
  Partials       26       26              

Flag	Coverage Δ
CI-GHA	95.58% <100.00%> (+0.05%)	⬆️
MyPy	42.70% <87.71%> (+0.55%)	⬆️
OS-Linux	99.39% <100.00%> (+<0.01%)	⬆️
OS-Windows	99.38% <92.15%> (-0.11%)	⬇️
OS-macOS	99.02% <92.15%> (-0.09%)	⬇️
Py-3.10.11	98.91% <92.15%> (-0.09%)	⬇️
Py-3.10.15	99.24% <100.00%> (+<0.01%)	⬆️
Py-3.11.10	99.24% <100.00%> (+<0.01%)	⬆️
Py-3.11.9	98.91% <92.15%> (-0.09%)	⬇️
Py-3.12.6	99.24% <100.00%> (+<0.01%)	⬆️
Py-3.13.0-rc.3	99.24% <100.00%> (+<0.01%)	⬆️
Py-3.8.10	98.86% <92.15%> (-0.09%)	⬇️
Py-3.8.18	99.19% <100.00%> (+0.01%)	⬆️
Py-3.9.13	98.86% <92.15%> (-0.09%)	⬇️
Py-3.9.20	99.19% <100.00%> (+0.01%)	⬆️
Py-pypy7.3.11	99.14% <92.15%> (-0.10%)	⬇️
Py-pypy7.3.16	99.14% <92.15%> (-0.10%)	⬇️
Py-pypy7.3.17	99.16% <92.15%> (-0.10%)	⬇️
VM-macos-latest	99.02% <92.15%> (-0.09%)	⬇️
VM-ubuntu-latest	99.39% <100.00%> (+<0.01%)	⬆️
VM-windows-latest	99.38% <92.15%> (-0.11%)	⬇️
pytest	99.39% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

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

[webknjaz]

@mjpieters I started looking into using Hypothesis during PyCon (the maintainer helped me start).
Does this look like a yarl bug to you? https://github.com/aio-libs/yarl/actions/runs/4813151119/jobs/8569304512?pr=860#step:7:1489

[mjpieters]

@mjpieters I started looking into using Hypothesis during PyCon (the maintainer helped me start). Does this look like a yarl bug to you? https://github.com/aio-libs/yarl/actions/runs/4813151119/jobs/8569304512?pr=860#step:7:1489

I was going to look into that since I found this PR! It does look like %30 is not being decoded properly, so that does look an awful lot like a bug.

[mjpieters]

Actually, no this is not a bug in Yarl; it is a bug in your Hypothesis tests. unsafe contains '0':

test_quote_unquote_parameter(
    quoter=yarl._quoting_c._Quoter,
    unquoter=yarl._quoting_c._Unquoter,
    text_input='0',
    safe='',
    unsafe='0',   # <--- 0 is unsafe
    protected='',
    qs=False,
    requote=False,
)

With 0 unsafe, the unquoter must return %30.

Either not tell Hypothesis to provide input to unsafe, or account for characters in unsafe when comparing input and output.

[webknjaz]

@mjpieters yeah, I never used these and wasn't sure about the semantics which is why I asked you. My objective is to make the foundation for adding more Hypothesis testing in the future and so the contributors could look at the examples...

[webknjaz]

@mjpieters how about https://github.com/aio-libs/yarl/actions/runs/5206601078/jobs/9393336950?pr=860#step:7:1507 then?

[bdraco]

Got it working with a basic implementation. I figure we can always expand it later.

[bdraco]

not sure why it fails on 3.8 and 3.9 linux/mac only

[webknjaz]

@bdraco the tests don't fail but overall pytest session does, due to low coverage it's probably hitting fallback code branches:

FAIL Required test coverage of 98.95% not reached. Total coverage: 98.84%

(https://github.com/aio-libs/yarl/actions/runs/11194802544/job/31121813637?pr=860#step:10:2589)

We should just update .coveragerc to lower the expectations since those are for a single coverage run which will never hit all lines for a single test run. We rely on Codecov's combined metrics instead.

Also, could you use the “rebase” button on the UI for my branches, instead of producing foxtrot merges?

[bdraco]

@bdraco the tests don't fail but overall pytest session does, due to low coverage it's probably hitting fallback code branches:

FAIL Required test coverage of 98.95% not reached. Total coverage: 98.84%

(https://github.com/aio-libs/yarl/actions/runs/11194802544/job/31121813637?pr=860#step:10:2589)

We should just update .coveragerc to lower the expectations since those are for a single coverage run which will never hit all lines for a single test run. We rely on Codecov's combined metrics instead.

👍

Also, could you use the “rebase” button on the UI for my branches, instead of producing foxtrot merges?

I will keep that preference in mind for the future.

Also, I only show an update branch button and no rebase button in the UI, but happy to rebase manually instead.

[webknjaz]

Got it working with a basic implementation. I figure we can always expand it later.

That sounds reasonable. It'd be nice to have own strategy exposed under yarl.testing so that the end-users could use that strategy in their tests.

[webknjaz]

Also, I only show an update branch button and no rebase button in the UI, but happy to rebase manually instead.

@bdraco it's the same button, but it's a bit unobvious. There's an arrow with a drop-down on the update button (on its right side) that lets you select the mode (it won't let you select rebase if there are conflicts, though — in that case it'd require doing it locally).

[bdraco]

Also, I only show an update branch button and no rebase button in the UI, but happy to rebase manually instead.

@bdraco it's the same button, but it's a bit unobvious. There's an arrow with a drop-down on the update button (on its right side) that lets you select the mode (it won't let you select rebase if there are conflicts, though — in that case it'd require doing it locally).

O wow. I apparently have been missing that for years 🤦

Its unfortunate that GitHub doesn't have a configuration option to order it based on preference

[bdraco]

https://github.com/orgs/community/discussions/12032

[bdraco]

https://github.com/motlin/forbid-merge-commits-action might be an option

[webknjaz]

motlin/forbid-merge-commits-action might be an option

@bdraco so my strategy is tailored to individual PRs. If a contributor maintains their commits in the PR branch well, I prefer merging such PRs using the natural merge. And that's what I like to do in my PRs, as I control them. When I experiment, I may add some silly WIP commits but then, I always clean up the history before merging. When somebody has a mess, including but not limited to foxtrot merges in their PR, only then I consider using the “squash merge” option.
But since I don't like unnatural merge methods, I work with my own branches in a more self-aware way. So my ask is about my branches, not arbitrary contributors'. This is also because we can't expect random people on the internet to know how to use Git like a pro, which is why I wouldn't use automation to block such PRs and create barriers for the contributors (even though, my instinct is usually to tell people to maintain their commits well).

[bdraco]

Thanks for clarifying. Apologizes if I overstepped.

[webknjaz]

No problem! After all, I never explained this explicitly, nor did I deselect the checkbox to allow others to change the branch in my work. All's good :)