mutation-testing 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- mutation_testing-0.1.0/.claude/skills/markdown-extraction.md +172 -0
- mutation_testing-0.1.0/.devcontainer/devcontainer.json +15 -0
- mutation_testing-0.1.0/.github/workflows/publish.yml +19 -0
- mutation_testing-0.1.0/.gitignore +207 -0
- mutation_testing-0.1.0/LICENSE +21 -0
- mutation_testing-0.1.0/PKG-INFO +350 -0
- mutation_testing-0.1.0/README.md +323 -0
- mutation_testing-0.1.0/claude.md +166 -0
- mutation_testing-0.1.0/doc/ast_parsing_guide.md +1345 -0
- mutation_testing-0.1.0/docs/pytest_mutation_plan.md +1165 -0
- mutation_testing-0.1.0/example/mutations.yaml +60 -0
- mutation_testing-0.1.0/example/pyproject.toml +20 -0
- mutation_testing-0.1.0/example/run_mutations.py +63 -0
- mutation_testing-0.1.0/example/src/__init__.py +0 -0
- mutation_testing-0.1.0/example/src/calculator.py +25 -0
- mutation_testing-0.1.0/example/tests/__init__.py +0 -0
- mutation_testing-0.1.0/example/tests/test_calculator.py +27 -0
- mutation_testing-0.1.0/example/uv.lock +160 -0
- mutation_testing-0.1.0/md-extract.sh +157 -0
- mutation_testing-0.1.0/mutation_testing/__init__.py +37 -0
- mutation_testing-0.1.0/mutation_testing/config.py +70 -0
- mutation_testing-0.1.0/mutation_testing/core.py +306 -0
- mutation_testing-0.1.0/mutation_testing/coverage.py +249 -0
- mutation_testing-0.1.0/mutation_testing/runner.py +188 -0
- mutation_testing-0.1.0/pyproject.toml +43 -0
|
@@ -0,0 +1,172 @@
|
|
|
1
|
+
# Markdown Section Extraction Skill
|
|
2
|
+
|
|
3
|
+
Use this skill when you need to extract specific sections from markdown documentation files.
|
|
4
|
+
|
|
5
|
+
## When to Use This Skill
|
|
6
|
+
|
|
7
|
+
- User asks about specific sections of project documentation
|
|
8
|
+
- Need to retrieve targeted information from markdown files
|
|
9
|
+
- Want to list available documentation sections
|
|
10
|
+
- Need to extract all sections at a specific heading level
|
|
11
|
+
|
|
12
|
+
## Available Commands
|
|
13
|
+
|
|
14
|
+
The `md-extract.sh` script provides three main commands:
|
|
15
|
+
|
|
16
|
+
### 1. List Headers
|
|
17
|
+
Lists all headers in a markdown file with their line numbers and levels.
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
./md-extract.sh <file.md> list
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
**Example:**
|
|
24
|
+
```bash
|
|
25
|
+
./md-extract.sh claude.md list
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
**Output format:**
|
|
29
|
+
```
|
|
30
|
+
123 L1: Project Overview
|
|
31
|
+
145 L2: Core Goals
|
|
32
|
+
167 L3: Runtime Mutation Injection
|
|
33
|
+
```
|
|
34
|
+
|
|
35
|
+
### 2. Extract Section by Header Name
|
|
36
|
+
Extracts a specific section and all its subsections by header name.
|
|
37
|
+
|
|
38
|
+
```bash
|
|
39
|
+
./md-extract.sh <file.md> extract "<header-name>"
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
**Examples:**
|
|
43
|
+
```bash
|
|
44
|
+
# Extract the "Core Goals" section
|
|
45
|
+
./md-extract.sh claude.md extract "Core Goals"
|
|
46
|
+
|
|
47
|
+
# Extract the "Architecture" section
|
|
48
|
+
./md-extract.sh docs/pytest_mutation_plan.md extract "Architecture"
|
|
49
|
+
|
|
50
|
+
# Extract nested section
|
|
51
|
+
./md-extract.sh claude.md extract "Runtime Mutation Injection"
|
|
52
|
+
```
|
|
53
|
+
|
|
54
|
+
**Behavior:**
|
|
55
|
+
- Returns the header and all content until the next header of same or higher level
|
|
56
|
+
- Includes all subsections within the extracted section
|
|
57
|
+
- Case-sensitive header matching
|
|
58
|
+
|
|
59
|
+
### 3. Extract All Sections at Level
|
|
60
|
+
Extracts all sections at a specific heading level (1-6).
|
|
61
|
+
|
|
62
|
+
```bash
|
|
63
|
+
./md-extract.sh <file.md> extract-level <1-6>
|
|
64
|
+
```
|
|
65
|
+
|
|
66
|
+
**Examples:**
|
|
67
|
+
```bash
|
|
68
|
+
# Extract all top-level sections (# headers)
|
|
69
|
+
./md-extract.sh claude.md extract-level 1
|
|
70
|
+
|
|
71
|
+
# Extract all second-level sections (## headers)
|
|
72
|
+
./md-extract.sh claude.md extract-level 2
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Available Documentation Files
|
|
76
|
+
|
|
77
|
+
- `claude.md` - Project overview and goals
|
|
78
|
+
- `docs/pytest_mutation_plan.md` - Detailed implementation plan
|
|
79
|
+
- `doc/ast_parsing_guide.md` - AST parsing reference
|
|
80
|
+
- `README.md` - Basic project description
|
|
81
|
+
|
|
82
|
+
## Usage Patterns
|
|
83
|
+
|
|
84
|
+
### Pattern 1: User asks about project goals
|
|
85
|
+
```
|
|
86
|
+
User: "What are the goals of this project?"
|
|
87
|
+
|
|
88
|
+
Agent: Let me extract the goals section from the project documentation.
|
|
89
|
+
[Run: ./md-extract.sh claude.md extract "Core Goals"]
|
|
90
|
+
[Present the extracted content to user]
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
### Pattern 2: User wants overview of documentation structure
|
|
94
|
+
```
|
|
95
|
+
User: "What documentation is available?"
|
|
96
|
+
|
|
97
|
+
Agent: Let me list the sections in the main documentation.
|
|
98
|
+
[Run: ./md-extract.sh claude.md list]
|
|
99
|
+
[Present formatted list to user]
|
|
100
|
+
```
|
|
101
|
+
|
|
102
|
+
### Pattern 3: User asks about specific technical topic
|
|
103
|
+
```
|
|
104
|
+
User: "How does the architecture work?"
|
|
105
|
+
|
|
106
|
+
Agent: Let me extract the architecture section.
|
|
107
|
+
[Run: ./md-extract.sh claude.md extract "Architecture"]
|
|
108
|
+
[Present the content and answer follow-up questions]
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
### Pattern 4: User wants all main sections
|
|
112
|
+
```
|
|
113
|
+
User: "Give me an overview of all main topics"
|
|
114
|
+
|
|
115
|
+
Agent: Let me extract all top-level sections.
|
|
116
|
+
[Run: ./md-extract.sh claude.md extract-level 1]
|
|
117
|
+
[Summarize the sections for the user]
|
|
118
|
+
```
|
|
119
|
+
|
|
120
|
+
## Implementation Guidelines
|
|
121
|
+
|
|
122
|
+
1. **Always verify file exists** before running extraction
|
|
123
|
+
2. **Quote header names** when they contain spaces
|
|
124
|
+
3. **Use absolute or relative paths** correctly based on current directory
|
|
125
|
+
4. **Present extracted content** in a readable format to the user
|
|
126
|
+
5. **Offer to extract related sections** if user needs more context
|
|
127
|
+
|
|
128
|
+
## Error Handling
|
|
129
|
+
|
|
130
|
+
If a header is not found:
|
|
131
|
+
```
|
|
132
|
+
Error: Header 'X' not found in file.md
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
Solution: Run `list` command first to see available headers with correct spelling.
|
|
136
|
+
|
|
137
|
+
If file is not found:
|
|
138
|
+
```
|
|
139
|
+
Error: File 'X' not found
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
Solution: Check the file path and current working directory.
|
|
143
|
+
|
|
144
|
+
## Example Session
|
|
145
|
+
|
|
146
|
+
```
|
|
147
|
+
User: "What's this project about?"
|
|
148
|
+
|
|
149
|
+
Agent: Let me get the project overview for you.
|
|
150
|
+
|
|
151
|
+
[Runs: ./md-extract.sh claude.md extract "Project Overview"]
|
|
152
|
+
|
|
153
|
+
Agent: This is a Python mutation testing framework that validates test suite
|
|
154
|
+
quality by injecting runtime mutations and verifying tests catch them...
|
|
155
|
+
[continues with extracted content]
|
|
156
|
+
|
|
157
|
+
Would you like me to extract more details about any specific aspect?
|
|
158
|
+
```
|
|
159
|
+
|
|
160
|
+
## Tips for Best Results
|
|
161
|
+
|
|
162
|
+
- Start with `list` to see structure if unfamiliar with the file
|
|
163
|
+
- Use `extract` for focused information retrieval
|
|
164
|
+
- Use `extract-level 2` to get an overview of major topics
|
|
165
|
+
- Chain extractions: first get overview, then drill into specific sections
|
|
166
|
+
- Always provide context from the extracted content in your response
|
|
167
|
+
|
|
168
|
+
## Script Location
|
|
169
|
+
|
|
170
|
+
The script is located at: `./md-extract.sh` (project root)
|
|
171
|
+
|
|
172
|
+
Make sure you're in the project root directory when running commands, or use the full path.
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
{
|
|
2
|
+
"name": "Development Container",
|
|
3
|
+
"image": "mcr.microsoft.com/devcontainers/base:ubuntu",
|
|
4
|
+
"forwardPorts": [
|
|
5
|
+
6369
|
|
6
|
+
],
|
|
7
|
+
"remoteEnv": {
|
|
8
|
+
"ANTHROPIC_BASE_URL": "https://openrouter.ai/api",
|
|
9
|
+
"ANTHROPIC_AUTH_TOKEN": "${localEnv:OR_KEY}",
|
|
10
|
+
"ANTHROPIC_API_KEY": "",
|
|
11
|
+
"ANTHROPIC_DEFAULT_OPUS_MODEL": "xiaomi/mimo-v2-flash:free",
|
|
12
|
+
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "xiaomi/mimo-v2-flash:free",
|
|
13
|
+
"ANTHROPIC_DEFAULT_SONNET_MODEL": "xiaomi/mimo-v2-flash:free"
|
|
14
|
+
}
|
|
15
|
+
}
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
name: Publish to PyPI
|
|
2
|
+
|
|
3
|
+
on:
|
|
4
|
+
release:
|
|
5
|
+
types: [published]
|
|
6
|
+
|
|
7
|
+
jobs:
|
|
8
|
+
publish:
|
|
9
|
+
runs-on: ubuntu-latest
|
|
10
|
+
permissions:
|
|
11
|
+
id-token: write # required for trusted publishing
|
|
12
|
+
steps:
|
|
13
|
+
- uses: actions/checkout@v4
|
|
14
|
+
- uses: actions/setup-python@v5
|
|
15
|
+
with:
|
|
16
|
+
python-version: "3.12"
|
|
17
|
+
- run: pip install build
|
|
18
|
+
- run: python -m build
|
|
19
|
+
- uses: pypa/gh-action-pypi-publish@release/v1
|
|
@@ -0,0 +1,207 @@
|
|
|
1
|
+
# Byte-compiled / optimized / DLL files
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[codz]
|
|
4
|
+
*$py.class
|
|
5
|
+
|
|
6
|
+
# C extensions
|
|
7
|
+
*.so
|
|
8
|
+
|
|
9
|
+
# Distribution / packaging
|
|
10
|
+
.Python
|
|
11
|
+
build/
|
|
12
|
+
develop-eggs/
|
|
13
|
+
dist/
|
|
14
|
+
downloads/
|
|
15
|
+
eggs/
|
|
16
|
+
.eggs/
|
|
17
|
+
lib/
|
|
18
|
+
lib64/
|
|
19
|
+
parts/
|
|
20
|
+
sdist/
|
|
21
|
+
var/
|
|
22
|
+
wheels/
|
|
23
|
+
share/python-wheels/
|
|
24
|
+
*.egg-info/
|
|
25
|
+
.installed.cfg
|
|
26
|
+
*.egg
|
|
27
|
+
MANIFEST
|
|
28
|
+
|
|
29
|
+
# PyInstaller
|
|
30
|
+
# Usually these files are written by a python script from a template
|
|
31
|
+
# before PyInstaller builds the exe, so as to inject date/other infos into it.
|
|
32
|
+
*.manifest
|
|
33
|
+
*.spec
|
|
34
|
+
|
|
35
|
+
# Installer logs
|
|
36
|
+
pip-log.txt
|
|
37
|
+
pip-delete-this-directory.txt
|
|
38
|
+
|
|
39
|
+
# Unit test / coverage reports
|
|
40
|
+
htmlcov/
|
|
41
|
+
.tox/
|
|
42
|
+
.nox/
|
|
43
|
+
.coverage
|
|
44
|
+
.coverage.*
|
|
45
|
+
.cache
|
|
46
|
+
nosetests.xml
|
|
47
|
+
coverage.xml
|
|
48
|
+
*.cover
|
|
49
|
+
*.py.cover
|
|
50
|
+
.hypothesis/
|
|
51
|
+
.pytest_cache/
|
|
52
|
+
cover/
|
|
53
|
+
|
|
54
|
+
# Translations
|
|
55
|
+
*.mo
|
|
56
|
+
*.pot
|
|
57
|
+
|
|
58
|
+
# Django stuff:
|
|
59
|
+
*.log
|
|
60
|
+
local_settings.py
|
|
61
|
+
db.sqlite3
|
|
62
|
+
db.sqlite3-journal
|
|
63
|
+
|
|
64
|
+
# Flask stuff:
|
|
65
|
+
instance/
|
|
66
|
+
.webassets-cache
|
|
67
|
+
|
|
68
|
+
# Scrapy stuff:
|
|
69
|
+
.scrapy
|
|
70
|
+
|
|
71
|
+
# Sphinx documentation
|
|
72
|
+
docs/_build/
|
|
73
|
+
|
|
74
|
+
# PyBuilder
|
|
75
|
+
.pybuilder/
|
|
76
|
+
target/
|
|
77
|
+
|
|
78
|
+
# Jupyter Notebook
|
|
79
|
+
.ipynb_checkpoints
|
|
80
|
+
|
|
81
|
+
# IPython
|
|
82
|
+
profile_default/
|
|
83
|
+
ipython_config.py
|
|
84
|
+
|
|
85
|
+
# pyenv
|
|
86
|
+
# For a library or package, you might want to ignore these files since the code is
|
|
87
|
+
# intended to run in multiple environments; otherwise, check them in:
|
|
88
|
+
# .python-version
|
|
89
|
+
|
|
90
|
+
# pipenv
|
|
91
|
+
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
|
|
92
|
+
# However, in case of collaboration, if having platform-specific dependencies or dependencies
|
|
93
|
+
# having no cross-platform support, pipenv may install dependencies that don't work, or not
|
|
94
|
+
# install all needed dependencies.
|
|
95
|
+
#Pipfile.lock
|
|
96
|
+
|
|
97
|
+
# UV
|
|
98
|
+
# Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
|
|
99
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
100
|
+
# commonly ignored for libraries.
|
|
101
|
+
#uv.lock
|
|
102
|
+
|
|
103
|
+
# poetry
|
|
104
|
+
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
|
|
105
|
+
# This is especially recommended for binary packages to ensure reproducibility, and is more
|
|
106
|
+
# commonly ignored for libraries.
|
|
107
|
+
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
|
|
108
|
+
#poetry.lock
|
|
109
|
+
#poetry.toml
|
|
110
|
+
|
|
111
|
+
# pdm
|
|
112
|
+
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
|
|
113
|
+
# pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
|
|
114
|
+
# https://pdm-project.org/en/latest/usage/project/#working-with-version-control
|
|
115
|
+
#pdm.lock
|
|
116
|
+
#pdm.toml
|
|
117
|
+
.pdm-python
|
|
118
|
+
.pdm-build/
|
|
119
|
+
|
|
120
|
+
# pixi
|
|
121
|
+
# Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
|
|
122
|
+
#pixi.lock
|
|
123
|
+
# Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
|
|
124
|
+
# in the .venv directory. It is recommended not to include this directory in version control.
|
|
125
|
+
.pixi
|
|
126
|
+
|
|
127
|
+
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
|
|
128
|
+
__pypackages__/
|
|
129
|
+
|
|
130
|
+
# Celery stuff
|
|
131
|
+
celerybeat-schedule
|
|
132
|
+
celerybeat.pid
|
|
133
|
+
|
|
134
|
+
# SageMath parsed files
|
|
135
|
+
*.sage.py
|
|
136
|
+
|
|
137
|
+
# Environments
|
|
138
|
+
.env
|
|
139
|
+
.envrc
|
|
140
|
+
.venv
|
|
141
|
+
env/
|
|
142
|
+
venv/
|
|
143
|
+
ENV/
|
|
144
|
+
env.bak/
|
|
145
|
+
venv.bak/
|
|
146
|
+
|
|
147
|
+
# Spyder project settings
|
|
148
|
+
.spyderproject
|
|
149
|
+
.spyproject
|
|
150
|
+
|
|
151
|
+
# Rope project settings
|
|
152
|
+
.ropeproject
|
|
153
|
+
|
|
154
|
+
# mkdocs documentation
|
|
155
|
+
/site
|
|
156
|
+
|
|
157
|
+
# mypy
|
|
158
|
+
.mypy_cache/
|
|
159
|
+
.dmypy.json
|
|
160
|
+
dmypy.json
|
|
161
|
+
|
|
162
|
+
# Pyre type checker
|
|
163
|
+
.pyre/
|
|
164
|
+
|
|
165
|
+
# pytype static type analyzer
|
|
166
|
+
.pytype/
|
|
167
|
+
|
|
168
|
+
# Cython debug symbols
|
|
169
|
+
cython_debug/
|
|
170
|
+
|
|
171
|
+
# PyCharm
|
|
172
|
+
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
|
|
173
|
+
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
|
|
174
|
+
# and can be added to the global gitignore or merged into this file. For a more nuclear
|
|
175
|
+
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
|
|
176
|
+
#.idea/
|
|
177
|
+
|
|
178
|
+
# Abstra
|
|
179
|
+
# Abstra is an AI-powered process automation framework.
|
|
180
|
+
# Ignore directories containing user credentials, local state, and settings.
|
|
181
|
+
# Learn more at https://abstra.io/docs
|
|
182
|
+
.abstra/
|
|
183
|
+
|
|
184
|
+
# Visual Studio Code
|
|
185
|
+
# Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore
|
|
186
|
+
# that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
|
|
187
|
+
# and can be added to the global gitignore or merged into this file. However, if you prefer,
|
|
188
|
+
# you could uncomment the following to ignore the entire vscode folder
|
|
189
|
+
# .vscode/
|
|
190
|
+
|
|
191
|
+
# Ruff stuff:
|
|
192
|
+
.ruff_cache/
|
|
193
|
+
|
|
194
|
+
# PyPI configuration file
|
|
195
|
+
.pypirc
|
|
196
|
+
|
|
197
|
+
# Cursor
|
|
198
|
+
# Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
|
|
199
|
+
# exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
|
|
200
|
+
# refer to https://docs.cursor.com/context/ignore-files
|
|
201
|
+
.cursorignore
|
|
202
|
+
.cursorindexingignore
|
|
203
|
+
|
|
204
|
+
# Marimo
|
|
205
|
+
marimo/_static/
|
|
206
|
+
marimo/_lsp/
|
|
207
|
+
__marimo__/
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 YeahWick
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|