You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
BUG: Fixpandas-dev#46726: wrong result with varying window size min/max rolling calc. (Reduced scope of the original check-in to avoid docstring errors.)
Write your scripts that run a series of nondterministic tests "forever", and output any bugs found.
5
+
6
+
## But We Have Unit Tests for That (pytest)?
7
+
Not quite!
8
+
- Unit tests are only designed to run a handful of known tests, and are just a "sanity check" before letting your changes in. Pytest is also a deterministic set that is designed to, once passed, keep passing until a breaking change is made. Bug hunters, on the other hand, are designed to keep hunting for new bugs.
9
+
- Unit tests are supposed to finish in finite time (to say the least!), and have to cover the entire codebase; therefore by design they cannot be very extensive or be able to cover all thinkable and untinkable inputs (which is what we expect from bug hunters).
10
+
- You will simply not be able to commit a typical bug-hunter script into the "tests" directory: a typical bug hunter script has patterns (by design) that will violate pre-commit checks, namely random number generators without a seed, to promote nondeterminism.
11
+
12
+
## Good Tone Conventions
13
+
This is a new directory, and is not covered by specialized pre-commit checks, so it is a good idea to follow these basic recommendations:
14
+
- Have code in your bug hunter script that for a failed test will present (e.g. print or save to a file) all the inputs necessary to reproduce the behavior.
15
+
- Try to reuse as much code as possible. Supposedly whatever code is written here can appear in unit-tests as well. One way to reuse it is to define your basic test structure in pytest (the "teats" directory), and reuse it here with imports.
0 commit comments