Profile and measure slow Django test suites with Django's runner, pytest-django, shell timing, py-spy, cProfile, pytest durations, and profiler visualizations.
SkillScore91Maintained
Automatic
◆QA & Test Engineering pack
Last verified 8/16/2026
What it changes
Passed 20 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill91%
Checks it passed that the model alone missed
Recommends shell time command to measure wall-clock baseline duration.
Recommends py-spy as the initial profiler for low-overhead whole-run sampling.
Recommends shell time command for recording total wall-clock execution duration.
and 1 more in the full report
3 fixed17 passed either way1 still failing1 broke
Pass-rate lift
+9 pp
Tokens
-4%
Agent turns
0%
Response time
-37%
Model gemini-3.6-flashMeasured 8/16/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
I need to audit our Django test suite's runtime performance in our CI build pipeline because execution times are spiking. Please inspect our test suite run and produce an assessment detailing the baseline execution command and total duration, the main time-consuming phases or individual slow tests, which profiler tool to apply and why, plus a prioritized list of three immediate next steps sorted by expected impact.
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends shell time command for recording total wall-clock execution duration.
Missed
Passed
Recommends py-spy as the initial profiler for low-overhead whole-run sampling.
Missed
Passed
Limits action items to top three prioritized actions.
Passed
Passed
case-03 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md62 lines2 files
Django Test Profiling
Use this skill before changing a Django test suite for speed. Measurement decides which optimization is worth doing; otherwise it is easy to spend time on harmless settings while the real cost sits in startup, database setup, fixture construction, or a small set of slow tests.
Measurement Workflow
Capture a full wall-clock baseline.
Prefer shell timing because it includes Python startup, Django import time, test discovery, database setup, and teardown.
Record the exact command, environment, and repeat count.
Separate framework phases when possible.
For Django's runner, use --timing to see database setup and teardown.
For pytest, compare shell timing with pytest --durations.
Find the slowest tests.
For pytest-django, start with pytest --durations 20.
For Django's runner, use an existing slow-test plugin or a small custom runner only when the project does not already have one.
Profile only after you know where the time goes.
Use py-spy first for a low-overhead whole-run view.
Use cProfile when you need exhaustive Python call data.
Convert the result into a ranked action list.
Identify whether the expensive part is startup, database creation, repeated setup, test data, query count, I/O, cache/file/storage access, or a specific test body.
Hand off to django-test-performance, django-test-data, or django-test-parallelization when the next step fits those skills.
Commands
time python manage.py test
python manage.py test --timing
pytest --durations 20
For profiling command variants and interpretation guidance, read profiler-commands.md.
Decision Rules
Treat shell timing as the authoritative user-visible duration.
Use Django --timing when database setup or teardown may dominate.
Gather, classify, prioritize, respond to, and act on developer documentation feedback from page feedback, support issues, community forums, field notes, sentiment, surveys, user councils, bug reports, and user follow-up. Use when setting up docs feedback channels, triaging docs issues, responding to frustrated users, prioritizing doc fixes, or converting feedback into actionable documentation work.