Test-drive Django validation across model constraints, forms, ModelForms, views, template errors, duplicate handling, and redirects.
SkillScore91Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 20 of 22 test cases with the skill, and 14 of 22 without it.
Without skill64%
With skill91%
Checks it passed that the model alone missed
Recommends documenting rule ownership broken down by layer
Recommends using assertNumQueries in tests to enforce query efficiency
Explains testing DRF serializer validity using Serializer(data=...).is_valid()
and 5 more in the full report
7 fixed13 passed either way1 still failing1 broke
Pass-rate lift
+27 pp
Tokens
+1%
Agent turns
0%
Response time
-25%
Model gemini-3.6-flashMeasured 8/15/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
We finished implementing custom form validation for a user profile view in Django. What specific summary details should be recorded before marking the verification complete?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends documenting rule ownership broken down by layer
Missed
Passed
Recommends providing evidence that invalid data was prevented from saving along with the focused test execution command
Missed
Passed
case-19 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md56 lines2 files
Django Forms Validation TDD
Use this skill to place validation tests at the layer that owns the rule, then prove the user-facing error path still works. Django validation often crosses model, form, view, and template boundaries; keep those responsibilities explicit.
Source Traceability
Primary source: Harry Percival, Test-Driven Development with Python, 3rd ed. Guidance is transformed and paraphrased from chapters 14-16 and Appendix A, especially model constraints, form validation, ModelForm tradeoffs, view-level error surfacing, and duplicate item handling.
Workflow
Classify the validation rule.
Data integrity belongs near the model or database constraint.
User input shape and presentation belong in a form.
Request branching and redirects belong in the view.
Error rendering belongs in the template.
Write the lowest useful failing test.
Model constraint or validation test for persistence rules.
Form test for field errors, cleaning, and save behavior.
View test for HTTP status, redirect, template, and invalid-save prevention.
Functional test only for a critical user journey.
Prove invalid data is not persisted.
Check both the error response and database state when the risk is saving bad input.
For uniqueness, cover duplicate behavior at the level that actually enforces it.
Refactor toward the right boundary.
Move validation from views to forms when the view is parsing form details.
Move integrity rules to constraints when the database must protect them.
Keep presentation logic in templates unless Python code clearly owns it.
Read validation-patterns.md for layer choices and common Django edge cases.
Decision Rules
If the rule must hold outside HTTP, test it below the view.
If save() can bypass validation, test the path that actually runs validation or enforce the rule with constraints.
If a ModelForm couples the UI to unwanted model details, use a plain form or customize fields deliberately.
If a refactor changes field names, IDs, or templates, keep one user-facing check for the rendered contract.
If duplicate handling depends on the database, include the database-level behavior in coverage.