mutmut 3.6.0__tar.gz → 3.8.0__tar.gz

{mutmut-3.6.0 → mutmut-3.8.0}/HISTORY.rst

@@ -1,6 +1,64 @@
 Changelog
 ---------
 
+3.8.0
+~~~~~~~~~~
+
+* Fix obsolete test names never being removed from ``mutants/mutmut-stats.json`` (`#564`)
+
+* Fix ``# pragma: no mutate block`` being silently ignored when placed on an ``else``, ``except``, ``except*`` or ``finally`` header, and on the ``try`` line of a ``try``/``except*`` (`#559`)
+
+* Fix ``# pragma: no mutate`` being silently ignored on ``match`` and ``case`` headers (`#554`)
+
+* Fix mutants being reported as survived when a test uses ``patch.dict(os.environ, ..., clear=True)`` (`#511`, `#552`)
+
+* Fix `mutate_only_covered_lines` mutating code that coverage.py excludes from measurement (`# pragma: no cover`, `exclude_lines`, `exclude_also`) (`#547`)
+
+* Fix mutations that delete ignored code. Dropping a `case` from a `match`, or an argument from a call, is a mutation of the enclosing node, so it used to be made even when the removed lines were themselves ignored (`#547`)
+
+* Fix methods of decorated classes (for example `@dataclass`) not being mutated (`#480`, `#539`)
+
+* Fix time measurement including test setup/teardown instead of only the main test run (`#544`)
+
+* Fix mutants stopped by the CPU-time limit being reported as killed instead of timed out (`#565`)
+
+* Fix ``mutate_only_covered_lines`` breaking when the test suite imports a dependency that cannot be initialized twice in one process, which raised for numpy and libyaml, produced misleading type errors for cryptography, and segfaulted for asyncpg. Coverage is now gathered in a separate process, so the modules the coverage run imports are no longer unloaded and re-imported in the main process (`#528`, `#566`)
+
+* Mutate the condition of ternary expressions (`#196`, `#546`)
+
+* Add a ``process_isolation`` config for choosing which process mutant workers are forked from. The new ``forkserver`` strategy keeps mutmut's main process free of pytest and your ``conftest.py``, routing every fork through a dedicated fork server process, for test setups that are not fork-safe (``gevent``, ``grpc``, ``torch``). Tune what it preloads with ``forkserver_warmup`` (`#578`, `#566`)
+
+* Add a `badge` command that writes a shields.io endpoint file, for publishing the mutation score (`#549`)
+
+* Support python3.15 (`#551`)
+
+3.7.0
+~~~~~
+
+* Fix the trampoline dropping a generator's return value, so ``yield from`` on a mutated generator no longer yields ``None`` instead of its result
+
+* Fix async generators, so that `aclose()`/`athrow()` are handled by the `except`/`finally` blocks of the mutated function instead of being swallowed by the trampoline
+
+* Fix `max_stack_depth` when a test changes the working directory (for example via a tmpdir fixture)
+
+* Fix `type_check_command` reporting type errors in copied files that have no mutants
+
+* Per-function source hashing for incremental cache invalidation — only re-test mutants in functions that changed
+
+* Cross-call dependency tracking — invalidate mutants in callers when a called function changes
+
+* Use git to detect non-Python dependency file changes; falls back to a curated file list when git is unavailable
+
+* Add `cache_invalidation_exclude` config to suppress noisy files from change detection
+
+* Add `use_git_change_detection` config (default true) to opt out of git-based detection
+
+* Add `uv.lock`, `poetry.lock`, `Pipfile.lock`, and `pdm.lock` to the list of files copied by default
+
+* Invalidate cached results automatically when result-affecting config fields change
+
+* Make `mutmut browse`, `show` and `apply` much faster and use far less memory, by storing where each mutant is in the mutated file instead of parsing the whole file to find it
+
 3.6.0
 ~~~~~
 
@@ -559,7 +617,7 @@ Thanks goes out Marcelo Da Cruz Pinto, Savo Kovačević,
 
 * Dict literals looking like `dict(a=foo)` now have mutated keys. You can also declare synonyms in setup.cfg.
 
-* Fix "from x import *"
+* Fix ``from x import *``
 
 
 0.0.6 (2017-06-13)

{mutmut-3.6.0 → mutmut-3.8.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: mutmut
-Version: 3.6.0
+Version: 3.8.0
 Summary: mutation testing for Python 3
 Keywords: mutmut,mutant,mutation,test,testing
 Author: Anders Hovmöller
@@ -16,19 +16,20 @@ Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Classifier: Programming Language :: Python :: 3.14
-Requires-Dist: click>=8.0.0
+Classifier: Programming Language :: Python :: 3.15
+Requires-Dist: click>=8.4.2
 Requires-Dist: coverage>=7.3.0
-Requires-Dist: libcst>=1.8.5
+Requires-Dist: libcst>=1.9.0
 Requires-Dist: pytest>=6.2.5
-Requires-Dist: setproctitle>=1.1.0
+Requires-Dist: setproctitle>=1.3.7
 Requires-Dist: textual>=1.0.0
 Requires-Dist: toml>=0.10.2 ; python_full_version < '3.11'
 Requires-Python: >=3.10
-Project-URL: Changelog, https://github.com/boxed/mutmut/blob/main/HISTORY.rst
-Project-URL: Documentation, https://mutmut.readthedocs.io/en/latest/
 Project-URL: Homepage, https://github.com/boxed/mutmut
-Project-URL: Issues, https://github.com/boxed/mutmut/issues
+Project-URL: Documentation, https://mutmut.readthedocs.io/en/latest/
 Project-URL: Repository, https://github.com/boxed/mutmut
+Project-URL: Issues, https://github.com/boxed/mutmut/issues
+Project-URL: Changelog, https://github.com/boxed/mutmut/blob/main/HISTORY.rst
 Description-Content-Type: text/x-rst
 
 mutmut - python mutation tester
@@ -80,7 +81,7 @@ You can get started with a simple:
     pip install mutmut
     mutmut run
 
-This will by run pytest on tests in the "tests" or "test" folder and
+This will run pytest on tests in the "tests" or "test" folder and
 it will try to figure out where the code to mutate is.
 
 
@@ -96,7 +97,7 @@ You can also write a mutant to disk from the `browse` interface, or via
 source code control and committed before you apply a mutant!
 
 
-If during the installation you get an error for the `libcst` dependency mentioning the lack of a rust compiler on your system, it is because your architecture does not have a prebuilt binary for `libcst` and it requires both `rustc` and `cargo` from the [rust toolchain](https://www.rust-lang.org/tools/install) to be built. This is known for at least the `x86_64-darwin` architecture.
+If during the installation you get an error for the `libcst` dependency mentioning the lack of a rust compiler on your system, it is because your architecture does not have a prebuilt binary for `libcst` and it requires both `rustc` and `cargo` from the `rust toolchain <https://www.rust-lang.org/tools/install>`_ to be built. This is known for at least the `x86_64-darwin` architecture.
 
 
 Wildcards for testing mutants
@@ -202,6 +203,11 @@ If you only want to mutate lines that are called (according to coverage.py), you
 
     mutate_only_covered_lines=true
 
+This also honours the lines coverage.py is told to leave out of its measurement, so code
+marked with `# pragma: no cover`, or matched by your `exclude_lines`/`exclude_also`
+settings, is not mutated either. Such code is not held to your test suite, so mutants
+there could only ever show up as survivors.
+
 
 Filter generated mutants with type checker
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -264,6 +270,108 @@ macOS at your own risk, or to disable it on other platforms), set ``use_setproct
     use_setproctitle = false
 
 
+Process isolation (``fork`` vs ``forkserver``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "fork"  # or "forkserver"
+
+Both strategies require ``os.fork``, so they are POSIX-only.
+
+``fork`` (default)
+    Mutmut's main process imports pytest and runs your test suite to collect
+    stats, then forks one child per mutant. This is fast and needs no
+    configuration, but every mutant worker inherits whatever your test setup
+    left behind in that process: monkey-patched sockets, running event loops,
+    background threads, open database connections, CUDA contexts. If any of
+    that is not fork-safe, the workers can hang, segfault, or report nonsense.
+
+``forkserver``
+    Mutmut's main process never imports pytest or your ``conftest.py``. It forks
+    a dedicated *fork server* child, and that child does the importing once and
+    forks a worker per mutant::
+
+        main process (clean) -> fork server (imports pytest) -> N mutant workers
+
+    Because the fork server only imports and forks, and never runs a test
+    itself, every worker starts from the same predictable state. This is the
+    same design as the ``forkserver`` start method in Python's
+    ``multiprocessing``, and it is still only one pytest import for the whole
+    run, so it is not slower than ``fork`` in the normal case.
+
+**Which one should you use?** Start with ``fork``. Switch to ``forkserver`` if
+your run hangs, crashes, or gives results you cannot reproduce by running the
+tests by hand, and your test setup touches something known to be fork-unsafe,
+such as ``gevent.monkey.patch_all()``, ``grpc``, or ``torch``. It is also the
+better choice if you simply do not want your session-scoped setup living in the
+process that forks mutants.
+
+
+Tuning what the fork server preloads
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``forkserver_warmup`` controls how much the fork server imports before it starts
+forking workers. It only applies when ``process_isolation = "forkserver"``.
+Anything imported in the fork server is inherited by every  worker, and anything
+left out is imported in each worker.
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "forkserver"
+    forkserver_warmup = "collect"  # "collect" (default), "import" or "none"
+
+``collect`` (default)
+    Run ``pytest --collect-only``, which imports your ``conftest.py``, your
+    plugins and your test modules. This is the right default for most projects
+    and usually the fastest.
+
+``import``
+    Import only the modules listed in ``preload_modules_file`` (one dotted
+    module name per line; blank lines and ``#`` comments are ignored, and
+    modules that fail to import are skipped). Use this when test *collection*
+    itself has side effects you do not want every worker to share, but you still
+    want your slow imports warmed up.
+
+``none``
+    Import nothing beyond what running a single test requires. This is the
+    slowest option, and the most isolated. It is mostly useful for working out
+    whether a warmup side effect is what is breaking your run.
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "forkserver"
+    forkserver_warmup = "import"
+    preload_modules_file = "mutmut_preload.txt"
+
+If the fork server itself crashes, mutmut starts a new one and re-submits the
+mutants that were in flight, up to ``max_forkserver_restarts`` times (default
+``3``) before giving up with a ``ForkServerCrashError``:
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    max_forkserver_restarts = 3
+
+The fork server and its workers cannot write to the console without mangling
+mutmut's progress output, so they log to a file instead. Logging is off unless
+you ask for it with ``log_to_file`` (or ``debug``):
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    log_to_file = true
+    log_file_path = "mutants/mutmut-debug.log"
+
+
 Disabling mutation on specific code
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -434,6 +542,77 @@ You can add and override pytest arguments:
     also_copy = ["mutmut_pytest.ini"]
 
 
+Detecting dependency and config changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Between runs, mutmut only re-tests mutants in functions whose source changed.
+Changes outside your Python source — a dependency upgrade, a data file, a
+config file — cannot be tied to a function, so they would otherwise be missed
+and you would get cached results that no longer reflect reality.
+
+To catch this, mutmut detects non-Python files that changed since the last full
+run and warns you about them. If your project is a git repository and git is
+installed, mutmut uses git (a soft dependency no extra package is required) to
+find every changed non-Python file, respecting your `.gitignore`. Python files
+are excluded because their changes are already tracked per function.
+
+On a full run with git available, mutmut also records the content hashes of the
+tracked non-Python files. This means a later run in an environment without git
+(for example a different CI stage) can still detect changes to that known set of
+files, even though it cannot discover brand-new ones.
+
+When git is unavailable, mutmut falls back to hashing a curated set of build and
+dependency files:
+
+- `pyproject.toml`
+- `setup.cfg`
+- `setup.py`
+- `requirements*.txt`
+- `poetry.lock`
+- `uv.lock`
+- `Pipfile`
+- `Pipfile.lock`
+
+You can watch additional files (for example data files your tests depend on)
+with the `cache_invalidation_files` config, which accepts glob patterns
+resolved against the project root. These are checked even when git ignores them,
+and are never dropped by the exclusions below:
+
+.. code-block:: toml
+
+    cache_invalidation_files = [ "queries/*.sql", "config/*.yaml" ]
+
+Git detection reports every changed non-Python file, so mutmut drops files that
+practically never affect tests (markdown, `LICENSE`, `CHANGELOG`, `docs/`, git
+and editor metadata, ...). Exclude additional noisy files with
+`cache_invalidation_exclude` (glob patterns, `*` spans directories):
+
+.. code-block:: toml
+
+    cache_invalidation_exclude = [ "*.json", "fixtures/snapshots/*" ]
+
+When a watched file changes, `on_dependency_change` controls what happens:
+
+- `warn` (default): list the changed files and keep the cache.
+- `rerun`: re-test all mutants.
+- `ignore`: do nothing.
+
+.. code-block:: toml
+
+    on_dependency_change = "warn"
+
+Git detection is on by default; disable it (forcing the curated-list fallback)
+with:
+
+.. code-block:: toml
+
+    use_git_change_detection = false
+
+Changes to mutmut's own result-affecting config (such as `pytest_add_cli_args`,
+`type_check_command`, or the timeout settings) are always detected and
+invalidate the affected cached results automatically.
+
+
 Unstable configs
 ~~~~~~~~~~~~~~~~
 
@@ -473,9 +652,24 @@ This section describes how to work with mutmut to enhance your test suite.
 4. Press `r` to rerun the mutant and see if you successfully managed to kill it.
 
 Mutmut keeps the data of what it has done and the mutants in the `mutants/`
-directory.If  you want to make sure you run a full mutmut run you can delete
+directory. If you want to make sure you run a full mutmut run you can delete
 this directory to start from scratch.
 
+
+Mutation score badges
+---------------------
+
+`mutmut badge` turns `mutmut export-cicd-stats` output into `Shields endpoint JSON <https://shields.io/badges/endpoint-badge>`_:
+
+.. code-block:: console
+
+    mutmut export-cicd-stats
+    mutmut badge --output mutation-score.json
+
+.. code-block:: md
+
+    ![mutation](https://img.shields.io/endpoint?url=https://example.com/mutation-score.json)
+
 Contributing to Mutmut
 ----------------------
 

{mutmut-3.6.0 → mutmut-3.8.0}/README.rst

@@ -47,7 +47,7 @@ You can get started with a simple:
     pip install mutmut
     mutmut run
 
-This will by run pytest on tests in the "tests" or "test" folder and
+This will run pytest on tests in the "tests" or "test" folder and
 it will try to figure out where the code to mutate is.
 
 
@@ -63,7 +63,7 @@ You can also write a mutant to disk from the `browse` interface, or via
 source code control and committed before you apply a mutant!
 
 
-If during the installation you get an error for the `libcst` dependency mentioning the lack of a rust compiler on your system, it is because your architecture does not have a prebuilt binary for `libcst` and it requires both `rustc` and `cargo` from the [rust toolchain](https://www.rust-lang.org/tools/install) to be built. This is known for at least the `x86_64-darwin` architecture.
+If during the installation you get an error for the `libcst` dependency mentioning the lack of a rust compiler on your system, it is because your architecture does not have a prebuilt binary for `libcst` and it requires both `rustc` and `cargo` from the `rust toolchain <https://www.rust-lang.org/tools/install>`_ to be built. This is known for at least the `x86_64-darwin` architecture.
 
 
 Wildcards for testing mutants
@@ -169,6 +169,11 @@ If you only want to mutate lines that are called (according to coverage.py), you
 
     mutate_only_covered_lines=true
 
+This also honours the lines coverage.py is told to leave out of its measurement, so code
+marked with `# pragma: no cover`, or matched by your `exclude_lines`/`exclude_also`
+settings, is not mutated either. Such code is not held to your test suite, so mutants
+there could only ever show up as survivors.
+
 
 Filter generated mutants with type checker
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -231,6 +236,108 @@ macOS at your own risk, or to disable it on other platforms), set ``use_setproct
     use_setproctitle = false
 
 
+Process isolation (``fork`` vs ``forkserver``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "fork"  # or "forkserver"
+
+Both strategies require ``os.fork``, so they are POSIX-only.
+
+``fork`` (default)
+    Mutmut's main process imports pytest and runs your test suite to collect
+    stats, then forks one child per mutant. This is fast and needs no
+    configuration, but every mutant worker inherits whatever your test setup
+    left behind in that process: monkey-patched sockets, running event loops,
+    background threads, open database connections, CUDA contexts. If any of
+    that is not fork-safe, the workers can hang, segfault, or report nonsense.
+
+``forkserver``
+    Mutmut's main process never imports pytest or your ``conftest.py``. It forks
+    a dedicated *fork server* child, and that child does the importing once and
+    forks a worker per mutant::
+
+        main process (clean) -> fork server (imports pytest) -> N mutant workers
+
+    Because the fork server only imports and forks, and never runs a test
+    itself, every worker starts from the same predictable state. This is the
+    same design as the ``forkserver`` start method in Python's
+    ``multiprocessing``, and it is still only one pytest import for the whole
+    run, so it is not slower than ``fork`` in the normal case.
+
+**Which one should you use?** Start with ``fork``. Switch to ``forkserver`` if
+your run hangs, crashes, or gives results you cannot reproduce by running the
+tests by hand, and your test setup touches something known to be fork-unsafe,
+such as ``gevent.monkey.patch_all()``, ``grpc``, or ``torch``. It is also the
+better choice if you simply do not want your session-scoped setup living in the
+process that forks mutants.
+
+
+Tuning what the fork server preloads
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+``forkserver_warmup`` controls how much the fork server imports before it starts
+forking workers. It only applies when ``process_isolation = "forkserver"``.
+Anything imported in the fork server is inherited by every  worker, and anything
+left out is imported in each worker.
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "forkserver"
+    forkserver_warmup = "collect"  # "collect" (default), "import" or "none"
+
+``collect`` (default)
+    Run ``pytest --collect-only``, which imports your ``conftest.py``, your
+    plugins and your test modules. This is the right default for most projects
+    and usually the fastest.
+
+``import``
+    Import only the modules listed in ``preload_modules_file`` (one dotted
+    module name per line; blank lines and ``#`` comments are ignored, and
+    modules that fail to import are skipped). Use this when test *collection*
+    itself has side effects you do not want every worker to share, but you still
+    want your slow imports warmed up.
+
+``none``
+    Import nothing beyond what running a single test requires. This is the
+    slowest option, and the most isolated. It is mostly useful for working out
+    whether a warmup side effect is what is breaking your run.
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    process_isolation = "forkserver"
+    forkserver_warmup = "import"
+    preload_modules_file = "mutmut_preload.txt"
+
+If the fork server itself crashes, mutmut starts a new one and re-submits the
+mutants that were in flight, up to ``max_forkserver_restarts`` times (default
+``3``) before giving up with a ``ForkServerCrashError``:
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    max_forkserver_restarts = 3
+
+The fork server and its workers cannot write to the console without mangling
+mutmut's progress output, so they log to a file instead. Logging is off unless
+you ask for it with ``log_to_file`` (or ``debug``):
+
+.. code-block:: toml
+
+    # pyproject.toml
+    [tool.mutmut]
+    log_to_file = true
+    log_file_path = "mutants/mutmut-debug.log"
+
+
 Disabling mutation on specific code
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -401,6 +508,77 @@ You can add and override pytest arguments:
     also_copy = ["mutmut_pytest.ini"]
 
 
+Detecting dependency and config changes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Between runs, mutmut only re-tests mutants in functions whose source changed.
+Changes outside your Python source — a dependency upgrade, a data file, a
+config file — cannot be tied to a function, so they would otherwise be missed
+and you would get cached results that no longer reflect reality.
+
+To catch this, mutmut detects non-Python files that changed since the last full
+run and warns you about them. If your project is a git repository and git is
+installed, mutmut uses git (a soft dependency no extra package is required) to
+find every changed non-Python file, respecting your `.gitignore`. Python files
+are excluded because their changes are already tracked per function.
+
+On a full run with git available, mutmut also records the content hashes of the
+tracked non-Python files. This means a later run in an environment without git
+(for example a different CI stage) can still detect changes to that known set of
+files, even though it cannot discover brand-new ones.
+
+When git is unavailable, mutmut falls back to hashing a curated set of build and
+dependency files:
+
+- `pyproject.toml`
+- `setup.cfg`
+- `setup.py`
+- `requirements*.txt`
+- `poetry.lock`
+- `uv.lock`
+- `Pipfile`
+- `Pipfile.lock`
+
+You can watch additional files (for example data files your tests depend on)
+with the `cache_invalidation_files` config, which accepts glob patterns
+resolved against the project root. These are checked even when git ignores them,
+and are never dropped by the exclusions below:
+
+.. code-block:: toml
+
+    cache_invalidation_files = [ "queries/*.sql", "config/*.yaml" ]
+
+Git detection reports every changed non-Python file, so mutmut drops files that
+practically never affect tests (markdown, `LICENSE`, `CHANGELOG`, `docs/`, git
+and editor metadata, ...). Exclude additional noisy files with
+`cache_invalidation_exclude` (glob patterns, `*` spans directories):
+
+.. code-block:: toml
+
+    cache_invalidation_exclude = [ "*.json", "fixtures/snapshots/*" ]
+
+When a watched file changes, `on_dependency_change` controls what happens:
+
+- `warn` (default): list the changed files and keep the cache.
+- `rerun`: re-test all mutants.
+- `ignore`: do nothing.
+
+.. code-block:: toml
+
+    on_dependency_change = "warn"
+
+Git detection is on by default; disable it (forcing the curated-list fallback)
+with:
+
+.. code-block:: toml
+
+    use_git_change_detection = false
+
+Changes to mutmut's own result-affecting config (such as `pytest_add_cli_args`,
+`type_check_command`, or the timeout settings) are always detected and
+invalidate the affected cached results automatically.
+
+
 Unstable configs
 ~~~~~~~~~~~~~~~~
 
@@ -440,9 +618,24 @@ This section describes how to work with mutmut to enhance your test suite.
 4. Press `r` to rerun the mutant and see if you successfully managed to kill it.
 
 Mutmut keeps the data of what it has done and the mutants in the `mutants/`
-directory.If  you want to make sure you run a full mutmut run you can delete
+directory. If you want to make sure you run a full mutmut run you can delete
 this directory to start from scratch.
 
+
+Mutation score badges
+---------------------
+
+`mutmut badge` turns `mutmut export-cicd-stats` output into `Shields endpoint JSON <https://shields.io/badges/endpoint-badge>`_:
+
+.. code-block:: console
+
+    mutmut export-cicd-stats
+    mutmut badge --output mutation-score.json
+
+.. code-block:: md
+
+    ![mutation](https://img.shields.io/endpoint?url=https://example.com/mutation-score.json)
+
 Contributing to Mutmut
 ----------------------