Twingate / kubernetes-operator / 17780849958

97%

push

github

chore: Bump pytest-randomly from 3.16.0 to 4.0.1 (#784)

Bumps [pytest-randomly](https://github.com/pytest-dev/pytest-randomly)
from 3.16.0 to 4.0.1.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/pytest-dev/pytest-randomly/blob/main/CHANGELOG.rst">pytest-randomly's
changelog</a>.</em></p>
<blockquote>
<h2>4.0.1 (2025-09-12)</h2>
<ul>
<li>
<p>Remove the random state caching, which would grow without bound,
leaking memory in long test runs.
The caching was added to slightly speed up re-using the same (final)
seed, but since the final seed is now different for each test, it has no
effect.</p>
<p><code>PR
[#690](https://github.com/pytest-dev/pytest-randomly/issues/690)
&lt;https://github.com/pytest-dev/pytest-randomly/issues/687&gt;</code>__.</p>
</li>
<li>
<p>Modify Numpy seed restriction, replacing hashing with a modulo
operation.
The extra work to hash is unnecessary now that we generate a final seed
per test with CRC32.
This change saves ~500ns per test when Numpy is installed.</p>
<p><code>PR
[#691](https://github.com/pytest-dev/pytest-randomly/issues/691)
&lt;https://github.com/pytest-dev/pytest-randomly/issues/691&gt;</code>__.</p>
</li>
</ul>
<h2>4.0.0 (2025-09-10)</h2>
<ul>
<li>
<p>Support Python 3.14.</p>
</li>
<li>
<p>Use a different random seed per test, based on the test ID.</p>
<p>This change should mean that tests exercise more random data values
in a given run, and that any randomly-generated identifiers have a lower
chance of collision when stored in a shared resource like a
database.</p>
<p><code>PR
[#687](https://github.com/pytest-dev/pytest-randomly/issues/687)
&lt;https://github.com/pytest-dev/pytest-randomly/issues/687&gt;</code><strong>.
Thanks to Bryce Drennan for the suggestion in <code>Issue
[#600](https://github.com/pytest-dev/pytest-randomly/issues/600)
&lt;https://github.com/pytest-dev/pytest-randomly/issues/600&gt;</code></strong>
and initial implementation in <code>PR
[#617](https://g... (continued)

199 of 224 branches covered (88.84%)

Branch coverage included in aggregate %.

1221 of 1246 relevant lines covered (97.99%)

0.98 hits per line