pax_global_header 0000666 0000000 0000000 00000000064 15127240603 0014512 g ustar 00root root 0000000 0000000 52 comment=7799c3fea7bc9e8356cc6c316e9ad329a92917b3
HypothesisWorks-hypothesis-7799c3f/ 0000775 0000000 0000000 00000000000 15127240603 0017451 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.claude/ 0000775 0000000 0000000 00000000000 15127240603 0020764 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.claude/CLAUDE.md 0000664 0000000 0000000 00000004024 15127240603 0022243 0 ustar 00root root 0000000 0000000 # Hypothesis Development Guide
## Essential Reading
**Always read `CONTRIBUTING.rst` before starting work**, especially before writing tests or creating a PR.
## Testing
### Running Tests
Run tests using the build system:
- **Quick test run**: `./build.sh check-coverage` (curated subset with coverage verification)
- **Python version-specific**: `./build.sh check-py311` (replace with target version)
- **Fine-grained control**: `./build.sh tox py311-custom 3.11.3 -- [pytest args]`
- **Direct pytest** (after setup): `pytest hypothesis-python/tests/cover/`
### Writing Tests
**Never use `.example()` method in tests.** Instead:
- Use `@given` decorator directly for property-based tests
- Use helper functions from `tests.common.debug`:
- `minimal()` - find minimal failing example
- `find_any()` - find any example matching condition
- `assert_all_examples()` - verify all examples match predicate
- `assert_simple_property()` - verify simple properties with few examples
- `check_can_generate_examples()` - verify strategy can generate without error
## Changelog & Pull Requests
When creating a PR that changes `hypothesis-python/src/`:
1. Create `hypothesis-python/RELEASE.rst` with `RELEASE_TYPE: patch` (bugfixes) or `minor` (features)
2. See `RELEASE-sample.rst` for examples
3. **Imitate the style in `changelog.rst`** for consistency
4. Follow all changelog instructions in `CONTRIBUTING.rst`
**Note:** Test-only changes (no modifications to `src/`) do not require a RELEASE.rst file.
## Before Committing
1. Do a final edit pass on all code to ensure it is:
- **Concise** - remove unnecessary verbosity
- **Idiomatic** - follows Python and Hypothesis conventions
- **Minimally commented** - code should be self-documenting; only add comments where truly needed
2. **Run `./build.sh format; ./build.sh lint`** immediately before committing to auto-format and lint code
3. **Do not reference issues or PRs in commit messages** (e.g., avoid `Fixes #1234` or `See #5678`) - this clutters the issue timeline with unnecessary links
HypothesisWorks-hypothesis-7799c3f/.claude/commands/ 0000775 0000000 0000000 00000000000 15127240603 0022565 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.claude/commands/hypothesis.md 0000664 0000000 0000000 00000014710 15127240603 0025311 0 ustar 00root root 0000000 0000000 ---
description: Write property-based tests with Hypothesis
---
You are an expert developer of property-based tests, specifically using Hypothesis. Your goal is to identify and implement a small number of the most valuable Hypothesis tests that would benefit an existing codebase right now. You focus on clarity and maintainability, as your code will be reviewed by a developer. Your goal is to write precise tests, not comprehensive test suites.
Create and follow this todo list using the `Todo` tool:
1. [ ] Explore the provided code and identify valuable properties.
2. [ ] For each property, explore how its related code is used.
3. [ ] Write Hypothesis tests based on those properties.
4. [ ] Run the new Hypothesis tests, and reflect on the result.
## 1. Explore the code provided and identify valuable properties
First, explore the provided code, and identify valuable properties to test. A "valuable property" is an invariant or property about the code that is valuable to the codebase right now and that a knowledgeable developer for this codebase would have written a Hypothesis test for. The following are indicative of a valuable property:
- Would catch important bugs: Testing this property would reveal bugs that could cause serious issues.
- Documents important behavior: The property captures essential assumptions or guarantees that are important to future or current developers.
- Benefits significantly from Hypothesis: The property is concisely and powerfully expressed as a Hypothesis test, rather than a series of unit tests.
Keep the following in mind:
- Only identify properties that you strongly believe to be true and that are supported by evidence in the codebase, for example in docstrings, comments, code use patterns, type hints, etc. Do not include properties you are at all unsure about.
- Each property should provide a substantial improvement in testing power or clarity when expressed as a Hypothesis test, rather than a unit test. Properties which could have been equally well tested with a unit test are not particularly valuable.
- You may come across many possible properties. Your goal is to identify only a small number of the most valuable of those properties that would benefit the codebase right now.
If the provided code is large, focus on exploring in this order:
1. Public API functions/classes
2. Well-documented implementations of core functionality
3. Other implementations of core functionality
4. Internal/private helpers or utilities
Here are some examples of typical properties:
- Round-trip property: `decode(encode(x)) = x`, `parse(format(x)) = x`.
- Inverse relationship: `add/remove`, `push/pop`, `create/destroy`.
- Multiple equivalent implementations: Optimized vs reference implementation, complicated vs simple implementation.
- Mathematical property: Idempotence `f(f(x)) = f(x)`, commutativity `f(x, y) = f(y, x)`.
- Invariants: `len(filter(x)) <= len(x)`, `set(sort(x)) == set(x)`.
- Confluence: the order of function application doesn't matter (for example, in compiler optimization passes).
- Metamorphic property: some relationship between `f(x)` and `g(x)` holds for all x. For example, `sin(π − x) = sin(x)`.
- Single entry point. If a library has a narrow public API, a nice property-based test simply calls the library with valid inputs. Common in parsers.
While the following should generally not be tested:
- Obvious code wrappers
- Implementation details
The user has provided the following guidance for where and how to add Hypothesis tests: $ARGUMENTS.
- If the user has provided no direction, explore the entire codebase.
- If the user has provided a specific module, explore that module.
- If the user has provided a specific file, explore that file.
- If the user has provided a specific function, explore that function.
- If the user has given more complex guidance, follow that instead.
If you don't identify any valuable properties during exploration, that's fine; just tell the user as much, and then stop.
At the end of this step, you should tell the user the small list of the most valuable properties that you intend to test.
## 2. For each valuable property, explore how its related code is used
Before writing Hypothesis tests, explore how the codebase uses the related code of each valuable property. For example, if a property involves a function `some_function`, explore how the codebase calls `some_function`: what kinds of inputs are passed to it? in what context? etc. This helps correct any misunderstanding about the property before writing a test for it.
## 3. Write Hypothesis tests based on those properties.
For each property, write a new Hypothesis test for it, and add it to the codebase's test suite, following its existing testing conventions.
When writing Hypothesis tests, follow these guidelines:
- Each Hypothesis test should be both sound (tests only inputs the code can actually be called with) and complete (tests all inputs the code can actually be called with). Sometimes this is difficult. In those cases, prefer sound and mostly-complete tests; stopping at 90% completeness is better than over-complicating a test.
- Only place constraints on Hypothesis strategies if required by the code. For example, prefer `st.lists(...)` (with no size bound) to `st.lists(..., max_size=100)`, unless the property explicitly happens to only be valid for lists with no more than 100 elements.
## 4. Run the new Hypothesis tests, and reflect on the result.
Run the new Hypothesis tests that you just added. If any fail, reflect on why. Is the test failing because of a genuine bug, or because it's not testing the right thing? Often, when a new Hypothesis test fails, it's because the test generates inputs that the codebase assumes will never occur. If necessary, re-explore related parts of the codebase to check your understanding. You should only report that the codebase has a bug to the user if you are truly confident, and can justify why.
# Hypothesis Reference
Documentation reference (fetch with the `WebFetch` tool if required):
- **Strategies API reference**: https://hypothesis.readthedocs.io/en/latest/reference/strategies.html
- **Other API reference**: https://hypothesis.readthedocs.io/en/latest/reference/api.html
- Documents `@settings`, `@given`, etc.
These Hypothesis strategies are under-appreciated for how effective they are. Use them if they are a perfect or near-perfect fit for a property:
- `st.from_regex`
- `st.from_lark` - for context-free grammars
- `st.functions` - generates arbitrary callable functions
HypothesisWorks-hypothesis-7799c3f/.gitattributes 0000664 0000000 0000000 00000000176 15127240603 0022350 0 ustar 00root root 0000000 0000000 * text eol=lf
# Denote all files that are truly binary and should not be modified.
*.png binary
*.jpg binary
*.gif binary
HypothesisWorks-hypothesis-7799c3f/.github/ 0000775 0000000 0000000 00000000000 15127240603 0021011 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.github/CODEOWNERS 0000664 0000000 0000000 00000000553 15127240603 0022407 0 ustar 00root root 0000000 0000000 # Engine changes need to be approved by Zac-HD, as per
# https://github.com/HypothesisWorks/hypothesis/blob/master/guides/review.rst#engine-changes
/hypothesis-python/src/hypothesis/internal/conjecture/ @Zac-HD @Liam-DeVoe
# Changes to the paper also need to be approved by DRMacIver or Zac, as authors
/paper.md @DRMacIver @Zac-HD
/paper.bib @DRMacIver @Zac-HD
HypothesisWorks-hypothesis-7799c3f/.github/CODE_OF_CONDUCT.rst 0000664 0000000 0000000 00000005107 15127240603 0024023 0 ustar 00root root 0000000 0000000 ---------------
Code of conduct
---------------
Hypothesis's community is an inclusive space, and everyone in it is expected to abide by a code of conduct.
This applies in issues, pull requests, etc. as well as in the various Hypothesis community spaces.
At the high level the code of conduct goes like this:
1. Be kind
2. Be respectful
3. Be helpful
While it is impossible to enumerate everything that is unkind, disrespectful or unhelpful, here are some specific things that are definitely against the code of conduct:
1. -isms and -phobias (e.g. racism, sexism, transphobia and homophobia) are unkind, disrespectful *and* unhelpful. Just don't.
2. All software is broken. This is not a moral failing on the part of the authors. Don't give people a hard time for bad code.
3. It's OK not to know things. Everybody was a beginner once, nobody should be made to feel bad for it.
4. It's OK not to *want* to know something. If you think someone's question is fundamentally flawed, you should still ask permission before explaining what they should actually be asking.
5. Note that "I was just joking" is not a valid defence.
6. Don't suggest violence as a response to things, e.g. "People who do/think X should be Y-ed".
Even if you think it is obvious hyperbole and that it's very clear that no actual threat is meant,
it still contributes to a culture that makes people feel unsafe.
~~~~~~~~~~~~~~~~~~~~~~~~
Resolution of Violations
~~~~~~~~~~~~~~~~~~~~~~~~
David R. MacIver (the project lead) acts as the main point of contact and enforcer for code of conduct violations.
You can email him at david@drmaciver.com, or for violations on GitHub that you want to draw his attention to you can also mention him as @DRMacIver.
Other people (especially Hypothesis team members) should feel free to call people on code of conduct violations when they see them,
and it is appreciated but not required (especially if doing so would make you feel uncomfortable or unsafe).
We don't currently have a formal policy for resolutions and it's mostly based on subjective judgement calls,
but the high level intent is as follows:
* minor one-off infractions will just be met with a request not to repeat the behaviour and, where it would be useful,
for an apology.
* Major infractions and repeat offenders will be banned from the community.
If you disagree with David's judgement on any particular event, please feel free to tell him so.
Also, people who have a track record of bad behaviour outside of the Hypothesis community may be banned even
if they obey all these rules if their presence is making people uncomfortable.
HypothesisWorks-hypothesis-7799c3f/.github/actions/ 0000775 0000000 0000000 00000000000 15127240603 0022451 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.github/actions/install-base/ 0000775 0000000 0000000 00000000000 15127240603 0025027 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.github/actions/install-base/action.yml 0000664 0000000 0000000 00000003206 15127240603 0027030 0 ustar 00root root 0000000 0000000 name: "Install"
description: "Install python, then cache"
inputs:
python-version:
description: "Python version"
required: true
python-architecture:
description: "Python architecture, if not default for platform"
task:
description: "Task name"
required: true
runs:
using: "composite"
steps:
- name: Set up Python ${{ inputs.python-version }} ${{ inputs.python-architecture }}
uses: actions/setup-python@v4
with:
python-version: ${{ inputs.python-version }}
architecture: ${{ inputs.python-architecture }}
- name: Install dotnet6 for Pyjion
if: ${{ endsWith(inputs.task, '-pyjion') }}
shell: bash
run: |
wget https://packages.microsoft.com/config/ubuntu/21.04/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb
sudo apt-get update
sudo apt-get install -y apt-transport-https && \
sudo apt-get update && \
sudo apt-get install -y dotnet-sdk-6.0
- name: Restore cache
uses: actions/cache@v3
with:
path: |
.tox/
vendor/bundle
~/.cache
~/.local
~/appdata/local/pip/cache
~/Library/Caches/pip
~/wheelhouse
key: deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ inputs.python-version }}-${{ inputs.python-architecture }}-${{ inputs.task }}
restore-keys: |
deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ inputs.python-version }}-${{ inputs.python-architecture }}
deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}
deps-${{ runner.os }}
HypothesisWorks-hypothesis-7799c3f/.github/workflows/ 0000775 0000000 0000000 00000000000 15127240603 0023046 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/.github/workflows/fuzz.yml 0000664 0000000 0000000 00000006276 15127240603 0024602 0 ustar 00root root 0000000 0000000 name: Fuzzing
env:
# Tell pytest and other tools to produce coloured terminal output.
# Make sure this is also in the "passenv" section of the tox config.
PY_COLORS: 1
on:
# Run every six hours, for six hours each time
schedule:
- cron: '0 */6 * * *'
# Allow manual launching too so we can test any branch we like
workflow_dispatch:
# # Enable this and reduce the timeout below to check a PR is working
# pull_request:
# branches: [ master ]
jobs:
fuzz:
if: github.repository == 'HypothesisWorks/hypothesis' || github.event_name == 'workflow_dispatch'
# Keep all of this stuff synced with the setup in main.yml for CI
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: Set up Python 3.10
uses: actions/setup-python@v4
with:
python-version: "3.10.9"
- name: Restore cache
uses: actions/cache@v3
with:
path: |
~/.cache
~/wheelhouse
~/.local
vendor/bundle
.tox/
key: deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}-${{ matrix.task }}
restore-keys: |
deps-${{ runner.os }}-${{ hashFiles('requirements/*.txt') }}
deps-${{ runner.os }}
# OK, on to the fuzzing-specific part.
# We're going to stick everything into a single run for now instead of
# sharding it, because we'd have to manually specify all the databases
# we want to multiplex across and that would be annoying to manage.
# TODO: revisit this later; a redis-like service would be so much nicer.
- name: Download example database
uses: dawidd6/action-download-artifact@v9
with:
name: hypothesis-example-db
path: .hypothesis/examples
if_no_artifact_found: warn
workflow_conclusion: completed
- name: Install dependencies
run: |
pip install --upgrade setuptools pip wheel
pip install -r requirements/fuzzing.txt
pip install hypothesis-python/[all]
- name: Run hypofuzz session
continue-on-error: true
# The timeout ensures that we finish all steps within the six-hour
# maximum runtime for Github Actions.
# Then run the fuzzer on everything, as for our Windows CI; avoiding
# the --no-dashboard option because that also disables .patch writing.
run: |
timeout --preserve-status 5.5h \
hypothesis fuzz -- hypothesis-python/tests/ \
--ignore=hypothesis-python/tests/quality/ \
--ignore=hypothesis-python/tests/ghostwriter/
- name: Upload patch files with covering and failing `@example()`s
uses: actions/upload-artifact@v4
if: always()
with:
name: explicit-example-patches
path: .hypothesis/patches/latest_hypofuzz_*.patch
# Upload the database so it'll be persisted between runs.
# Note that we can also pull it down to use locally via
# https://hypothesis.readthedocs.io/en/latest/database.html#hypothesis.database.GitHubArtifactDatabase
- name: Upload example database
uses: actions/upload-artifact@v4
if: always()
with:
name: hypothesis-example-db
path: .hypothesis/examples
HypothesisWorks-hypothesis-7799c3f/.github/workflows/main.yml 0000664 0000000 0000000 00000025450 15127240603 0024523 0 ustar 00root root 0000000 0000000 name: Hypothesis CI
env:
# Tell pytest and other tools to produce coloured terminal output.
# Make sure this is also in the "passenv" section of the tox config.
PY_COLORS: 1
on:
push:
branches: [ master ]
pull_request:
branches: [ master ]
workflow_dispatch:
# Cancel in-progress PR builds if another commit is pushed.
# On non-PR builds, fall back to the globally-unique run_id and don't cancel.
concurrency:
group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
cancel-in-progress: true
jobs:
basic:
runs-on: ubuntu-latest
strategy:
matrix:
task:
- tox-cover
- tox-nocover
- tox-rest
- check-whole-repo-tests
- check-types-hypothesis
- lint
- check-format
fail-fast: false
env:
PYTHON_VERSION: "3.10"
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: "Install base for Python ${{ env.PYTHON_VERSION }}"
uses: ./.github/actions/install-base
with:
python-version: ${{ env.PYTHON_VERSION }}
task: ${{ matrix.task }}
- name: Install tox
if: ${{ startsWith(matrix.task, 'tox-') }}
run: |
pip install --upgrade setuptools pip wheel
pip install tox
- name: Run tests
run: |
export TASK=${{ matrix.task }}
if [[ $TASK == tox-* ]]; then
TOX_TASK="${TASK#tox-}"
cd hypothesis-python
tox -e $TOX_TASK
else
./build.sh
fi
req:
needs: [basic]
runs-on: ubuntu-latest
strategy:
matrix:
task:
- check-documentation
- check-types-api
- check-coverage
- check-conjecture-coverage
- check-py310-cover
- check-py310-nocover
- check-py310-niche
- check-pypy310-cover
# - check-py310-pyjion # see notes in tox.ini
- check-py311-cover
- check-py311-nocover
- check-py311-niche
- check-pypy311-cover
- check-py312-cover
- check-py312-nocover
- check-py312-niche
- check-py313-cover
- check-py313-nocover
- check-py313-niche
- check-py313t-cover
- check-py313t-nocover
- check-py313t-niche
- check-quality
- check-pytest62
- check-pytest62
- check-django60
- check-django42
- check-pandas22
- check-pandas21
- check-pandas20
- check-pandas15
- check-pandas14
- check-pandas13
## FIXME: actions update means Python builds without eg _bz2, which was required
# - check-py310-pandas12
# - check-py310-pandas11
fail-fast: false
env:
PYTHON_VERSION: "3.10"
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: "Install base for Python ${{ env.PYTHON_VERSION }}"
uses: ./.github/actions/install-base
with:
python-version: ${{ env.PYTHON_VERSION }}
task: ${{ matrix.task }}
- name: Run tests
run: |
export TASK=${{ matrix.task }}
if [[ $TASK == check-crosshair-custom-* ]]; then
GROUP="${TASK#check-crosshair-custom-}"
./build.sh check-crosshair-custom -- -n auto $(cd hypothesis-python && echo tests/$GROUP | xargs -n1 echo | grep -Ev "_py312|_py314" | xargs)
else
./build.sh
fi
- name: Upload coverage data
uses: actions/upload-artifact@v4
# Invoke the magic `always` function to run on both success and failure.
if: ${{ always() && endsWith(matrix.task, '-coverage') }}
with:
name: ${{ matrix.task }}-data
include-hidden-files: true
path: |
hypothesis-python/.coverage*
!hypothesis-python/.coveragerc
hypothesis-python/branch-check*
nonreq:
needs: [basic]
runs-on: ubuntu-latest
strategy:
matrix:
task:
- check-py314-cover
- check-py314-nocover
# Blocked by a 3.14rc1 bug. see
# https://github.com/HypothesisWorks/hypothesis/pull/4490#issuecomment-3144989862.
# Can revisit in 3.14rc2.
# - check-py314-niche
- check-py314t-cover
- check-py314t-nocover
- check-py314t-niche
# - check-py315-cover
# - check-py315-nocover
# - check-py315-niche
# - check-py315t-cover
# - check-py315t-nocover
# - check-py315t-niche
- check-django52
## `-cover` is too slow under crosshair; use a custom split
- check-crosshair-custom-cover/test_[a-d]*
- check-crosshair-custom-cover/test_[e-i]*
- check-crosshair-custom-cover/test_[j-r]*
- check-crosshair-custom-cover/test_[s-z]*
- check-crosshair-custom-pytest/test_*
- check-crosshair-custom-nocover/test_[a-d]*
- check-crosshair-custom-nocover/test_[e-i]*
- check-crosshair-custom-nocover/test_[j-r]*
- check-crosshair-custom-nocover/test_[s-z]*
# - check-crosshair-niche
- check-threading
- check-py310-oldestnumpy
- check-numpy-nightly
## Skip all the (inactive/old) Rust and Ruby tests pending fixes
# - lint-ruby
# - check-ruby-tests
# - check-rust-in-ruby-format
# - lint-rust-in-ruby
# - audit-rust-in-ruby
# - check-conjecture-rust-format
# - check-rust-tests
# - audit-conjecture-rust
# - lint-conjecture-rust
fail-fast: false
env:
PYTHON_VERSION: "3.10"
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: "Install base for Python ${{ env.PYTHON_VERSION }}"
uses: ./.github/actions/install-base
with:
python-version: ${{ env.PYTHON_VERSION }}
task: ${{ matrix.task }}
- name: Run tests
run: |
export TASK=${{ matrix.task }}
if [[ $TASK == check-crosshair-custom-* ]]; then
GROUP="${TASK#check-crosshair-custom-}"
./build.sh check-crosshair-custom -- -n auto $(cd hypothesis-python && echo tests/$GROUP | xargs -n1 echo | grep -Ev "_py312|_py314" | xargs)
else
./build.sh
fi
cross:
needs: [basic]
strategy:
matrix:
os:
- windows-latest
- macos-latest
python-version:
- "3.11"
- "3.13"
python-architecture:
- null
- "x86"
task:
- cover
- nocover
- rest
- alt-nocover
- alt-rest
exclude:
- { os: macos-latest, python-architecture: "x86" }
- { python-version: "3.13", python-architecture: "x86" }
- { python-version: "3.11", task: nocover }
- { python-version: "3.11", task: rest }
- { python-version: "3.13", task: alt-nocover }
- { python-version: "3.13", task: alt-rest }
fail-fast: false
runs-on: ${{ matrix.os }}
env:
# Override default from tox.ini
PYTHONWARNDEFAULTENCODING: ""
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: "Install base for Python ${{ matrix.python-version }} ${{ matrix.python-architecture }}"
uses: ./.github/actions/install-base
with:
python-version: ${{ matrix.python-version }}
python-architecture: ${{ matrix.python-architecture }}
task: ${{ matrix.task }}
- name: Install tox
run: |
pip install --upgrade setuptools pip wheel
pip install tox
- name: Run tests
working-directory: ./hypothesis-python
run: |
tox -e ${{ matrix.task }}
# See https://pyodide.org/en/stable/usage/building-and-testing-packages.html
# and https://github.com/numpy/numpy/blob/9a650391651c8486d8cb8b27b0e75aed5d36033e/.github/workflows/emscripten.yml
test-pyodide:
needs: [basic]
runs-on: ubuntu-latest
env:
NODE_VERSION: 22
# Note that the versions below are updated by `update_pyodide_versions()` in our weekly cronjob.
# The versions of pyodide-build and the Pyodide runtime may differ.
PYODIDE_VERSION: 0.29.0
PYODIDE_BUILD_VERSION: 0.30.9
PYTHON_VERSION: 3.13.2
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
- name: "Install base for Python ${{ env.PYTHON_VERSION }}"
uses: ./.github/actions/install-base
with:
python-version: ${{ env.PYTHON_VERSION }}
task: pyodide
- name: Set up Node
uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1
with:
node-version: ${{ env.NODE_VERSION }}
- name: Install pyodide-build and Pyodide cross-build environment
run: |
pip install pyodide-build==${{ env.PYODIDE_BUILD_VERSION }}
pyodide xbuildenv install ${{ env.PYODIDE_VERSION }}
- name: Set up Pyodide venv and install dependencies
run: |
pip install --upgrade setuptools pip wheel build
python -m build --wheel hypothesis-python --outdir dist/
pip download --dest=dist/ hypothesis-python/ pytest tzdata # fetch all the wheels
rm dist/packaging-*.whl # fails with `invalid metadata entry 'name'`
pyodide venv .venv-pyodide
source .venv-pyodide/bin/activate
pip install dist/*.whl
- name: Run tests
run: |
source .venv-pyodide/bin/activate
# pyodide can't run multiple processes internally, so parallelize explicitly over
# discovered test files instead (20 at a time)
TEST_FILES=$(ls hypothesis-python/tests/cover/test*.py | grep -v "_py314")
echo "test files: $TEST_FILES"
parallel --max-procs 100% --max-args 20 --keep-order --line-buffer \
python -m pytest -p no:cacheprovider <<< $TEST_FILES
check-required:
if: always()
needs: [basic, req, cross]
runs-on: ubuntu-latest
steps:
- name: Check required jobs
uses: re-actors/alls-green@release/v1
with:
jobs: ${{ toJSON(needs) }}
deploy:
if: "github.event_name == 'push' && github.repository == 'HypothesisWorks/hypothesis'"
runs-on: ubuntu-latest
needs: [check-required]
strategy:
matrix:
task:
- deploy
fail-fast: false
steps:
- uses: actions/checkout@v3
with:
fetch-depth: 0
token: ${{ secrets.GH_TOKEN }}
- uses: ./.github/actions/install-base
with:
python-version: "3.10"
- name: Deploy package
env:
GH_TOKEN: ${{ secrets.GH_TOKEN }}
TWINE_PASSWORD: ${{ secrets.PYPI_TOKEN }}
GEM_HOST_API_KEY: ${{ secrets.RUBYGEMS_TOKEN }}
CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
run: |
TASK=${{ matrix.task }} ./build.sh
HypothesisWorks-hypothesis-7799c3f/.github/workflows/update-deps.yml 0000664 0000000 0000000 00000001605 15127240603 0026006 0 ustar 00root root 0000000 0000000 name: Update pinned dependencies
on:
schedule:
- cron: 0 0 * * 0
workflow_dispatch:
jobs:
release:
name: Update pinned dependencies
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Set up Python 3.10
uses: actions/setup-python@v4
with:
python-version: '3.10'
- name: Update pinned dependencies
run: ./build.sh upgrade-requirements
- name: Open pull request
uses: peter-evans/create-pull-request@v7
with:
token: ${{secrets.GH_TOKEN}}
delete-branch: true
title: Update pinned dependencies
body: |
Automatically update pinned dependencies
commit-message: 'Update pinned dependencies'
committer: 'CI on behalf of the Hypothesis team '
author: 'CI on behalf of the Hypothesis team '
HypothesisWorks-hypothesis-7799c3f/.github/workflows/website.yml 0000664 0000000 0000000 00000002217 15127240603 0025235 0 ustar 00root root 0000000 0000000 name: Build website & deploy to GitHub Pages
on:
# Runs on pushes targeting the default branch
push:
branches: ["master"]
# Allows you to run this workflow manually from the Actions tab
workflow_dispatch:
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
contents: read
pages: write
id-token: write
# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
group: "pages"
cancel-in-progress: false
jobs:
# Single deploy job since we're just deploying
deploy:
environment:
name: github-pages
url: ${{ steps.deployment.outputs.page_url }}
runs-on: ubuntu-latest
steps:
- name: Checkout
uses: actions/checkout@v4
- name: Build website
run: ./build.sh website
- name: Upload artifact
uses: actions/upload-pages-artifact@v3
with:
path: 'website/output/'
- name: Deploy to GitHub Pages
id: deployment
uses: actions/deploy-pages@v4
HypothesisWorks-hypothesis-7799c3f/.gitignore 0000664 0000000 0000000 00000002351 15127240603 0021442 0 ustar 00root root 0000000 0000000 # mypyc
*.so
# misc (editors, file systems, etc)
*.swo
*.swp
.idea
.vagrant
.DS_Store
.hypothesis
.vscode/
.claude/settings.local.json
# generic build components
.runtimes
/hypothesis-python/branch-check*
/pythonpython3.*
/pythonpypy3.*
.pyodide-xbuildenv
# python
*.pyc
*.pyo
venv*
.cache
.pytest_cache
.mypy_cache
docs/_build
*.egg-info
_build
.tox
.coverage
.coverage.*
.pypirc
htmlcov
build
dist
.doctrees/
.v*/
# encrypted files
secrets.tar
secrets
# Rust build targets
target
_site/
.sass-cache/
.docker
# =========================
# Operating System Files
# =========================
# OSX
# =========================
.AppleDouble
.LSOverride
# Thumbnails
._*
# Files that might appear on external disk
.Spotlight-V100
.Trashes
# Directories potentially created on remote AFP share
.AppleDB
.AppleDesktop
Network Trash Folder
Temporary Items
.apdisk
# Windows
# =========================
# Windows image file caches
Thumbs.db
ehthumbs.db
# Folder config file
Desktop.ini
# Recycle Bin used on file shares
$RECYCLE.BIN/
# Windows Installer files
*.cab
*.msi
*.msm
*.msp
# Windows shortcuts
*.lnk
sftp-config.json
# Vim files
*.sw*
__pycache__
.jekyll-metadata
HypothesisWorks.github.io.iml
jekyll.log
/website/output/
/t.py
HypothesisWorks-hypothesis-7799c3f/.readthedocs.yml 0000664 0000000 0000000 00000001236 15127240603 0022541 0 ustar 00root root 0000000 0000000 # Read the Docs configuration file
# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
# Required
version: 2
# Optionally build your docs in additional formats such as PDF and ePub
formats:
- htmlzip
- epub
# - pdf # busted by latex crash on unicode U+030A combining ring above, in text() docs
# Optionally set the version of Python and requirements required to build your docs
build:
os: ubuntu-22.04
tools:
python: "3.10"
python:
install:
- requirements: requirements/tools.txt
- path: hypothesis-python/
extra_requirements:
- all
sphinx:
configuration: hypothesis-python/docs/conf.py
HypothesisWorks-hypothesis-7799c3f/AUTHORS.rst 0000664 0000000 0000000 00000027770 15127240603 0021345 0 ustar 00root root 0000000 0000000 --------------------
List of Contributors
--------------------
The primary author for most of Hypothesis is David R. MacIver (me). However the following
people have also contributed work. As well as my thanks, they also have copyright over
their individual contributions.
.. NOTE - this list is in alphabetical order by first name (or handle).
* `Aaron Meurer `_
* `Adam Johnson `_
* `Adam Matan _`
* `Adam Sven Johnson `_
* `Afrida Tabassum `_ (afrida@gmail.com)
* `Afonso Silva `_ (ajcerejeira@gmail.com)
* `Agriya Khetarpal `_
* `Agustín Covarrubias `_ (gh@agucova.dev)
* `Akash Suresh `_ (akashsuresh36@gmail.com)
* `Alex Gaynor `_
* `Alex Stapleton `_
* `Alex Willmer `_ (alex@moreati.org.uk)
* `Andrea Pierré `_
* `Andrea Reina `_
* `Andrew Sansom `_
* `Anne Archibald `_
* `Arjoonn Sharma `_
* `Ben Anhalt `_
* `Ben Peterson `_ (killthrush@hotmail.com)
* `Benjamin Lee `_ (benjamindlee@me.com)
* `Benjamin Palmer `_
* `Bex Dunn `_ (bex.dunn@gmail.com)
* `Bill Tucker `_ (imbilltucker@gmail.com)
* `Brandon Chinn `_
* `Bryant Eisenbach `_
* `Buck Evan, copyright Google LLC `_
* `Cameron McGill `_
* `Carl Meyer `_
* `Charles O'Farrell `_
* `Charlie Tanksley `_
* `Chase Garner `_ (chase@garner.red)
* `Cheuk Ting Ho `_
* `Chris Down `_
* `Chris van Dronkelaar `_
* `Chris Wesseling `_
* `Christopher Martin `_ (ch.martin@gmail.com)
* `Claudio Jolowicz `_
* `Conrad Ho `_ (conrad.alwin.ho@gmail.com)
* `Cory Benfield `_
* `Cristi Cobzarenco `_ (cristi@reinfer.io)
* `Damon Francisco `_ (damontfrancisco@yahoo.com)
* `Daniel J. West `_
* `Daniel Knell `_ (contact@danielknell.co.uk)
* `David Bonner `_ (dbonner@gmail.com)
* `David Chudzicki `_ (dchudz@gmail.com)
* `David Mascharka `_
* `Dawn E. Collett `_
* `Derek Gustafson `_
* `Dion Misic `_ (dion.misic@gmail.com)
* `Dmitry Dygalo `_
* `Ed Rogers `-
* `Eduardo Enriquez `_ (eduardo.a.enriquez@gmail.com)
* `El Awbery `_
* `Emmanuel Leblond `_
* `Evan Tey `_
* `Felix Divo `_
* `Felix Grünewald `_
* `Felix Sheldon `_
* `Florian Bruhin `_
* `follower `_
* `Francesc Elies `_
* `Gabe Joseph `_
* `Gary Donovan `_
* `Genevieve Mendoza `_
* `George Macon `_
* `Glenn Lehman `_
* `Graham Williamson `_
* `Grant David Bachman `_ (grantbachman@gmail.com)
* `Gregory Petrosyan `_
* `Grzegorz Zieba `_ (g.zieba@erax.pl)
* `Grigorios Giannakopoulos `_
* `Hal Blackburn `_
* `Hugo van Kemenade `_
* `Humberto Rocha `_
* `Ilya Lebedev `_ (melevir@gmail.com)
* `Israel Fruchter `_
* `Ivan Tham `_
* `Iyassou Shimels `_
* `Jack Massey `_
* `Jakub Nabaglo `_ (j@nab.gl)
* `James Lamb `_
* `Jenny Rouleau `_
* `Jens Heinrich `_
* `Jens Tröger `_
* `Jeremy Thurgood `_
* `J.J. Green `_
* `JP Viljoen `_ (froztbyte@froztbyte.net)
* `Jochen Müller `_
* `Joseph Weston `_
* `Joey Tuong `_
* `Jonathan Gayvallet `_ (jonathan.gayvallet@orange.com)
* `Jonty Wareing `_ (jonty@jonty.co.uk)
* `Joshua Boone `_ (joshuaboone4190@gmail.com)
* `Joshua Munn `_ (public@elysee-munn.family)
* `jmhsi `_
* `Justus Magin `_
* `jwg4 `_
* `Kai Chen `_ (kaichen120@gmail.com)
* `Karthikeyan Singaravelan `_ (tir.karthi@gmail.com)
* `Katelyn Gigante `_
* `Katrina Durance `_
* `kbara `_
* `Keeri Tramm `_
* `Kristian Glass `_
* `Krzysztof Przybyła `_
* `Kyle Reeve `_ (krzw92@gmail.com)
* `Lampros Mountrakis `_
* `Lea Provenzano `_
* `Lee Begg `_
* `Liam DeVoe `_
* `Libor Martínek `_
* `Lisa Goeller `_
* `Louis Taylor `_
* `Luke Barone-Adesi `_
* `Lundy Bernard `_
* `Marco Ricci `_
* `Marco Sirabella `_
* `marekventur `_
* `Marius Gedminas `_ (marius@gedmin.as)
* `Markus Unterwaditzer `_ (markus@unterwaditzer.net)
* `Mateusz Sokół `_
* `Mathieu Paturel `_ (mathieu.paturel@gmail.com)
* `Matt Bachmann `_ (bachmann.matt@gmail.com)
* `Matthew Barber `_ (quitesimplymatt@gmail.com)
* `Max Nordlund `_ (max.nordlund@gmail.com)
* `Maxim Kulkin `_ (maxim.kulkin@gmail.com)
* `Mel Seto `_
* `Michel Alexandre Salim `_ (michel@michel-slm.name)
* `mulkieran `_
* `Munir Abdinur `_
* `Nathan Goldbaum `_
* `Nicholas Chammas `_
* `Nick Anyos `_
* `Nick Collins ` _
* `Nick Muoh `_ (nickspirit3@gmail.com)
* `Nicolas Erni `_
* `Nikita Sobolev `_ (mail@sobolevn.me)
* `Oleg Höfling `_ (oleg.hoefling@gmail.com)
* `Paul Ganssle `_ (paul@ganssle.io)
* `Paul Kehrer `_
* `Paul Lorett Amazona `_
* `Paul Stiverson `_
* `Pax (R. Margret) W. `_
* `Peadar Coyle `_ (peadarcoyle@gmail.com)
* `Petr Viktorin `_
* `Phillip Schanely `_ (pschanely@gmail.com)
* `Pierre-Jean Campigotto `_
* `Przemek Konopko `_
* `Reagan Lee `_
* `Richard Boulton `_ (richard@tartarus.org)
* `Richard Scholtens `_ (richardscholtens2@gmail.com)
* `Robert Howlett `_
* `Robert Knight `_ (robertknight@gmail.com)
* `Rodrigo Girão Serrão `_ (rodrigo@mathspp.com)
* `Rónán Carrigan `_ (rcarriga@tcd.ie)
* `Ruben Opdebeeck `_
* `Ryan Soklaski `_ (rsoklaski@gmail.com)
* `Ryan Turner `_ (ryan.turner@uber.com)
* `Sam Bishop (TechDragon) `_ (sam@techdragon.io)
* `Sam Clamons `_ (sclamons@gmail.com)
* `Sam Hames `_
* `Sam Watts `_
* `Sangarshanan `_ (sangarshanan1998@gmail.com)
* `Sanyam Khurana `_
* `Saul Shanabrook `_ (s.shanabrook@gmail.com)
* `Sebastiaan Zeeff `_ (sebastiaan.zeeff@ordina.nl)
* `Sharyar Memon `_ (smemon.cal@gmail.com)
* `Shaun Read `_
* `Shlok Gandhi `_ (shlok.gandhi@gmail.com)
* `Sogata Ray `_ (rayardinanda@gmail.com)
* `Stuart Cook `_
* `SuperStormer `_
* `Sushobhit `_ (sushobhitsolanki@gmail.com)
* `Tariq Khokhar `_ (tariq@khokhar.net)
* `Tessa Bradbury `_
* `Thea Koutsoukis `_
* `Thomas Ball `_ (bomtall1@hotmail.com)
* `Thomas Grainge `_
* `Thomas Kluyver `_ (thomas@kluyver.me.uk)
* `Tim Martin `_ (tim@asymptotic.co.uk)
* `Tom McDermott `_ (sponster@gmail.com)
* `Tom Milligan `_ (code@tommilligan.net)
* `Tyler Gibbons `_ (tyler.gibbons@flexport.com)
* `Tyler Nickerson `_
* `Vidya Rani `_ (vidyarani.d.g@gmail.com)
* `Vince Reuter `_ (vince.reuter@gmail.com)
* `Vincent Michel `_ (vxgmichel@gmail.com)
* `Viorel Pluta `_ (viopluta@gmail.com)
* `Vytautas Strimaitis `_
* `Will Hall `_ (wrsh07@gmail.com)
* `Will Thompson `_ (will@willthompson.co.uk)
* `Wilfred Hughes `_
* `Yiyang Zhan `_
* `Zac Hatfield-Dodds `_ (zac.hatfield.dodds@gmail.com)
* `Zebulun Arendsee `_ (zbwrnz@gmail.com)
HypothesisWorks-hypothesis-7799c3f/CITATION.cff 0000664 0000000 0000000 00000004214 15127240603 0021344 0 ustar 00root root 0000000 0000000 cff-version: 1.2.0
message: |
If you use Hypothesis as part of a published research project,
please cite our paper in the Journal of Open Source Software:
Text:
MacIver et al., (2019). Hypothesis: A new approach to property-based testing.
Journal of Open Source Software, 4(43), 1891, https://doi.org/10.21105/joss.01891
BibTeX:
@article{MacIver2019Hypothesis,
journal = {Journal of Open Source Software},
doi = {10.21105/joss.01891},
issn = {2475-9066},
number = {43},
publisher = {The Open Journal},
title = {Hypothesis: A new approach to property-based testing},
url = {http://dx.doi.org/10.21105/joss.01891},
volume = {4},
author = {MacIver, David and Hatfield-Dodds, Zac and Contributors, Many},
pages = {1891},
date = {2019-11-21},
year = {2019},
month = {11},
day = {21},
}
To reference a particular version of Hypothesis as a software artifact,
you can use the version-specific DOIs we create for each release under
https://doi.org/10.5281/zenodo.1412597
preferred-citation:
title: 'Hypothesis: A new approach to property-based testing'
date-released: 2019-11-21
type: article
doi: 10.21105/joss.01891
authors:
- family-names: MacIver
given-names: David R.
orcid: https://orcid.org/0000-0002-8635-3223
affiliation: Imperial College London
- family-names: Hatfield-Dodds
given-names: Zac
orcid: https://orcid.org/0000-0002-8646-8362
affiliation: Australian National University
- name: "many other contributors"
# Citation metadata for the software itself, as required by the CFF spec
doi: 10.5281/zenodo.1412597 # Version-independent DOI for the software archive
title: 'Hypothesis: Property-Based Testing for Python'
repository-code: https://github.com/HypothesisWorks/hypothesis
license: MPL-2.0
authors:
- family-names: MacIver
given-names: David R.
orcid: https://orcid.org/0000-0002-8635-3223
affiliation: Imperial College London
- family-names: Hatfield-Dodds
given-names: Zac
orcid: https://orcid.org/0000-0002-8646-8362
affiliation: Australian National University
- name: "many other contributors"
HypothesisWorks-hypothesis-7799c3f/CONTRIBUTING.rst 0000664 0000000 0000000 00000025243 15127240603 0022120 0 ustar 00root root 0000000 0000000 =============
Contributing
=============
First off: It's great that you want to contribute to Hypothesis! Thanks!
---------------------------------------
Just tell me how to make a pull request
---------------------------------------
1. Make your change and ensure it has adequate tests
2. Create ``hypothesis-python/RELEASE.rst`` with ``RELEASE_TYPE: patch``
for small bugfixes, or ``minor`` for new features. See ``RELEASE-sample.rst``
as an example.
3. Add yourself to the list in ``AUTHORS.rst`` and open a PR!
For more detail, read on; for even more, continue to the ``guides/`` directory!
------------------
Ways to Contribute
------------------
Hypothesis is a mature yet active project. This means that there are many
ways in which you can contribute.
For example, it's super useful and highly appreciated if you do any of:
* Submit bug reports
* Submit feature requests
* Write about Hypothesis
* Give a talk about Hypothesis
* Build libraries and tools on top of Hypothesis outside the main repo
* Submit PRs
If you build a Hypothesis strategy that you would like to be more widely known
please add it to the list of external strategies by preparing a PR against
the docs/strategies.rst file.
If you find an error in the documentation, please feel free to submit a PR that
fixes the error. Spot a tyop? Fix it up and send us a PR!
You can read more about how we document Hypothesis in ``guides/documentation.rst``
The process for submitting source code PRs is generally more involved
(don't worry, we'll help you through it), so do read the rest of this document.
If you're planning a larger change, the contributor guides (in the ``guides/``
directory) will make sure you're on the right track.
----------------------------------
Installing from source and testing
----------------------------------
If you want to install directly from the source code (e.g. because you want to
make changes and install the changed version) you can do this with:
.. code:: bash
pip install -r requirements/test.in
pip install -r requirements/tools.in
pip install -e hypothesis-python/
# You don't need to run the tests, but here's the command:
pytest hypothesis-python/tests/cover/
You may wish to do all of this in a
`virtualenv `_. For example:
.. code:: bash
python3 -m venv .venv
source .venv/bin/activate
pip install hypothesis
Will create an isolated environment where you can install and try out
Hypothesis without affecting your system packages.
-----------------------
Copyright and Licensing
-----------------------
It's important to make sure that you own the rights to the work you are submitting.
If it is done on work time, or you have a particularly onerous contract, make sure
you've checked with your employer.
All work in Hypothesis is licensed under the terms of the
`Mozilla Public License, version 2.0 `_. By
submitting a contribution you are agreeing to licence your work under those
terms.
Finally, if it is not there already, add your name (and a link to your GitHub
and email address if you want) to the list of contributors found in
AUTHORS.rst, in alphabetical order. It doesn't have to be your
"real" name (whatever that means), any sort of public identifier
is fine. In particular a GitHub account is sufficient.
-----------------------
The actual contribution
-----------------------
OK, so you want to make a contribution and have sorted out the legalese. What now?
First off: If you're planning on implementing a new feature, talk to us
first! Come `join us on the mailing list `_,
or open an issue. If it's really small feel free to open a work in progress pull request sketching
out the idea, but it's best to get feedback from the Hypothesis maintainers
before sinking a bunch of work into it.
If you're working on an existing issue, leave a comment so we can try to avoid
duplicating your work before you open a pull request.
In general work-in-progress pull requests are totally welcome if you want early feedback
or help with some of the tricky details. Don't be afraid to ask for help.
In order to get merged, a pull request will have to have a green build (naturally) and
to be approved by a Hypothesis maintainer (and, depending on what it is, possibly specifically
by DRMacIver). Most pull requests will also need to `write a changelog entry in
hypothesis-python/RELEASE.rst `_.
The review process is the same one that all changes to Hypothesis go through, regardless of
whether you're an established maintainer or entirely new to the project. It's very much
intended to be a collaborative one: It's not us telling you what we think is wrong with
your code, it's us working with you to produce something better together.
We have `a lengthy check list `_ of things we look for in a review. Feel
free to have a read of it in advance and go through it yourself if you'd like to. It's not
required, but it might speed up the process.
Once your pull request has a green build and has passed review, it will be merged to
master fairly promptly. This will immediately trigger a release! Don't be scared. If that
breaks things, that's our fault not yours - the whole point of this process is to ensure
that problems get caught before we merge rather than after.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pull request or external package?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
New strategies can be added to Hypothesis, or published as an external package
on PyPI - either is fine for most strategies. If in doubt, ask!
It's generally much easier to get things working outside, because there's
more freedom to experiment and fewer requirements in stability and API style.
We're happy to review and help with external packages as well as pull requests;
several parts of Hypothesis started life outside and were integrated later
(with permission, of course).
To help people find your package, please use the `Framework :: Hypothesis
`__ `trove classifier
`__. We also recommend naming your package
in the pattern of ``hypothesis-graphql`` and ``hypothesis-protobuf`` on PyPI.
On the other hand, being inside gets you access to some deeper implementation
features (if you need them) and better long-term guarantees about maintenance.
We particularly encourage pull requests for new composable primitives that
make implementing other strategies easier, or for widely used types in the
Python standard library. Strategies for other things are also welcome;
anything with external dependencies just goes in ``hypothesis.extra``.
~~~~~~~~~
The build
~~~~~~~~~
The build is driven by a ``build.sh`` shell script, which delegates to a custom Python-based build system.
Actually running the tests is managed by `tox `_, but the build system
will call out to the relevant tox environments so you mostly don't have to know anything about that
unless you want to make changes to the test config. You also mostly don't need to know anything about the build system
except to type ``./build.sh`` followed by the name of the task you want to run.
All of it will be checked on CI so you don't *have* to run anything locally, but you might
find it useful to do so: A full CI run can take up to twenty minutes,
so running a smaller set of tests locally can be helpful.
The build system should be "fairly" portable, but is currently only known to work on Linux or macOS. It *might* work
on a BSD or on Windows with cygwin installed, but it hasn't been tried. Windows with WSL does work,
as for Linux, and since OS-specific issues are rare for Hypothesis that's pretty useful.
If you try it and find it doesn't work, please do submit patches to fix that.
Some notable commands:
``./build.sh check-coverage`` will verify 100% code coverage by running a
curated subset of the test suite.
``./build.sh check-py311`` (etc.) will run most of the test suite against a
particular python version.
``./build.sh format`` will reformat your code according to the Hypothesis coding style. You should use this before each
commit ideally, but you only really have to use it when you want your code to be ready to merge.
You can also use ``./build.sh check-format``, which will run format and some linting and will then error if you have a
git diff. Note: This will error even if you started with a git diff, so if you've got any uncommitted changes
this will necessarily report an error.
Run ``./build.sh tasks`` for a list of all supported build task names.
Note: The build requires a lot of different versions of python, so rather than have you install them yourself,
the build system will install them itself in a local directory. This means that the first time you run a task you
may have to wait a while as the build downloads and installs the right version of python for you.
~~~~~~~~~~~~~
Running Tests
~~~~~~~~~~~~~
The tasks described above will run all of the tests (e.g. ``check-py311``). But
the ``tox`` task will give finer-grained control over the test runner. At a
high level, the task takes the form:
.. code-block::
./build.sh tox py311-custom 3.11.3 [tox args] -- [pytest args]
Namely, first provide the tox environment (see ``tox.ini``), then the python
version to test with, then any ``tox`` or ``pytest`` args as needed. For
example, to run all of the tests in the file
``tests/nocover/test_conjecture_engine.py`` with python 3.12:
.. code-block::
./build.sh tox py312-custom 3.12.7 -- tests/nocover/test_conjecture_engine.py
See the ``tox`` docs and ``pytest`` docs for more information:
* https://docs.pytest.org/en/latest/how-to/usage.html
* https://tox.wiki/en/latest/config.html#cli
^^^^^^^^^^^
Test Layout
^^^^^^^^^^^
See ``hypothesis-python/tests/README.rst``
^^^^^^^^^^^^^^^^
Useful Arguments
^^^^^^^^^^^^^^^^
Some useful arguments to pytest include:
* You can pass ``-n 0`` to turn off ``pytest-xdist``'s parallel test execution.
Sometimes for running just a small number of tests its startup time is longer
than the time it saves (this will vary from system to system), so this can
be helpful if you find yourself waiting on test runners to start a lot.
* You can use ``-k`` to select a subset of tests to run. This matches on substrings
of the test names. For example ``-kfoo`` will only run tests that have "foo" as
a substring of their name. You can also use composite expressions here.
e.g. ``-k'foo and not bar'`` will run anything containing foo that doesn't
also contain bar. `More information on how to select tests to run can be found
in the pytest documentation `__.
HypothesisWorks-hypothesis-7799c3f/LICENSE.txt 0000664 0000000 0000000 00000000636 15127240603 0021301 0 ustar 00root root 0000000 0000000 Copyright (c) 2013, David R. MacIver
All code in this repository except where explicitly noted otherwise is released
under the Mozilla Public License v 2.0. You can obtain a copy at https://mozilla.org/MPL/2.0/.
Some code in this repository comes from other projects. Where applicable, the
original copyright and license are noted and any modifications made are released
dual licensed with the original license.
HypothesisWorks-hypothesis-7799c3f/Makefile 0000664 0000000 0000000 00000000362 15127240603 0021112 0 ustar 00root root 0000000 0000000 # You don't need to use this Makefile and should use build.sh instead. This is
# just here so that us poor souls who remember the Make based system and keep
# typing "make target" can ease our transition to the new system.
%:
./build.sh $@
HypothesisWorks-hypothesis-7799c3f/README.md 0000664 0000000 0000000 00000003147 15127240603 0020735 0 ustar 00root root 0000000 0000000
# Hypothesis
* [Website](https://hypothesis.works/)
* [Documentation](https://hypothesis.readthedocs.io/en/latest/)
* [Source code](https://github.com/hypothesisWorks/hypothesis/)
* [Contributing](https://github.com/HypothesisWorks/hypothesis/blob/master/CONTRIBUTING.rst)
* [Community](https://hypothesis.readthedocs.io/en/latest/community.html)
Hypothesis is the property-based testing library for Python. With Hypothesis, you write tests which should pass for all inputs in whatever range you describe, and let Hypothesis randomly choose which of those inputs to check - including edge cases you might not have thought about. For example:
```python
from hypothesis import given, strategies as st
@given(st.lists(st.integers()))
def test_matches_builtin(ls):
assert sorted(ls) == my_sort(ls)
```
This randomized testing can catch bugs and edge cases that you didn't think of and wouldn't have found. In addition, when Hypothesis does find a bug, it doesn't just report any failing example — it reports the simplest possible one. This makes property-based tests a powerful tool for debugging, as well as testing.
For instance,
```python
def my_sort(ls):
return sorted(set(ls))
```
fails with the simplest possible failing example:
```
Falsifying example: test_matches_builtin(ls=[0, 0])
```
### Installation
To install Hypothesis:
```
pip install hypothesis
```
There are also [optional extras available](https://hypothesis.readthedocs.io/en/latest/extras.html).
HypothesisWorks-hypothesis-7799c3f/brand/ 0000775 0000000 0000000 00000000000 15127240603 0020537 5 ustar 00root root 0000000 0000000 HypothesisWorks-hypothesis-7799c3f/brand/README.rst 0000664 0000000 0000000 00000005411 15127240603 0022227 0 ustar 00root root 0000000 0000000 Logos and other pretty things
=============================
Hypothesis has a beautiful logo, thanks to the generous work of Libby Berrie
in `issue #1519 `__.
The `CogWorks class of 2019 `__ named the
dragonfly "Scout", as a job description and after *To Kill a Mockingbird*.
General guidelines:
- Prefer vector (``.svg``) formats to raster formats (``.png``) wherever possible.
However, some viewers don't handle the layers well - e.g. the left eye might be
drawn in front of the head - in which case you might prefer ``.png``.
- We consider the rainbow version to be canonical. The blue variant is provided
for cases such as monochome versions or printing with a limited palette.
With that in mind, you are welcome to use these logos to refer to Hypothesis -
and if you're not sure whether a specific use is OK, please get in touch and ask!
For example, we often bring Hypothesis stickers to conferences but can't make
it to everything. If you want to print your own Hypothesis stickers, upload
``sticker.png`` to `StickerMule `__
and pick one of the die-cut vinyl options - that's how we get ours!
.. image:: ./stickers.jpg
:alt: Hypothesis stickers suitable for your laptop
Zac also hands out `custom hard-enamel pins <./pin.jpg>`__ to Hypothesis contributors,
including anyone who has a pull request merged, does outreach, attends a paid workshop,
donates money, and so on - we value all kinds of contributions!
Like stickers, you can collect a pin in person at certain Python conferences, or
`sponsor Zac `__ to get them by Australia Post.
Colour palette in GIMP format
#############################
A `colour palette in GIMP format `__ (``.gpl``) is also provided
with the intent of making it easier to produce graphics and documents which
reuse the colours in the Hypothesis Dragonfly logo by Libby Berrie.
The ``hypothesis.gpl`` file should be copied or imported to the appropriate
location on your filesystem. For example:
- ``/usr/share/inkscape/palettes/`` for Inkscape on Ubuntu 18.08
- Edit -> Colors -> Import... then select the ``hypothesis.gpl`` file in Scribus
on Ubuntu 18.08
- Windows -> Dockable Dialogs -> Palettes -> Palettes Menu -> Add Palette ->
Import from file... then select the ``hypothesis.gpl`` file in GIMP on Ubuntu
18.08
Once imported, the colour palette is then available for easy manipulation of
colours within the user interface.
Inkscape:
.. image:: inkscape.png
:width: 800px
:align: left
:alt: Inkscape showing Hypothesis colour palette
GIMP:
.. image:: gimp.png
:width: 800px
:align: left
:alt: GIMP showing Hypothesis colour palette
HypothesisWorks-hypothesis-7799c3f/brand/dragonfly-blue.svg 0000664 0000000 0000000 00000044025 15127240603 0024177 0 ustar 00root root 0000000 0000000