django-forms-validation-tdd

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

1. 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.

1. 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.

1. 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.

1. 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](references/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.

Guardrails

• Do not rely only on Selenium for validation cases.
• Do not test every HTML string when form errors can be inspected directly.
• Do not assume Django model validation runs automatically on every save.
• Do not swallow IntegrityError without a user-facing path and a test.

Verification

Before finishing, record:

• Rule ownership by layer.
• Tests added or updated at model/form/view/browser level.
• Invalid-save prevention evidence where relevant.
• Focused Django test command and result.