You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: CONTRIBUTING.md
+38-2Lines changed: 38 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -59,15 +59,51 @@ This project follows
59
59
- All PRs, other than small documentation or typo fixes, should have a Issue assoicated. If not, please create one.
60
60
- Small, focused PRs. Keep changes minimal—one concern per PR.
61
61
- For bug fixes or features, please provide logs or screenshot after the fix is applied to help reviewers better understand the fix.
62
-
- Please add corresponding testing foryour code change if it's not covered by existing tests.
62
+
- Please include a `testing plan` section inyour PR to talk about how you will test. This will save timefor PR review. See `Testing Requirements` section for more details.
63
63
64
64
### Large or Complex Changes
65
65
For substantial features or architectural revisions:
66
66
67
67
- Open an Issue First: Outline your proposal, including design considerations and impact.
68
68
- Gather Feedback: Discuss with maintainers and the community to ensure alignment and avoid duplicate work
69
69
70
-
### Code reviews
70
+
## Testing Requirements
71
+
72
+
To maintain code quality and prevent regressions, all code changes must include comprehensive tests and verifiable end-to-end (E2E) evidence.
73
+
74
+
75
+
### Unit Tests
76
+
77
+
- **Coverage:** Cover new features, edge cases, error conditions, and typical use cases.
78
+
- **Location:** Add or update tests under `tests/unittests/`, following existing naming conventions (e.g., `test_<module>_<feature>.py`).
79
+
- **Framework:** Use `pytest`. Tests should be:
80
+
- Fast and isolated.
81
+
- Written clearly with descriptive names.
82
+
- Free of external dependencies (use mocks or fixtures as needed).
83
+
- **Quality:** Aim for high readability and maintainability; include docstrings or comments for complex scenarios.
84
+
85
+
### End-to-End (E2E) Tests
86
+
87
+
E2E tests ensure integrated flows work as intended. Your tests should cover all scenarios. Sometimes, it's also good to ensure relevant functionality is not impacted.
88
+
89
+
Depending on your change:
90
+
91
+
- **ADK Web:**
92
+
- Use the `adk web` to verify functionality.
93
+
- Capture and attach relevant screenshots demonstrating the UI/UX changes or outputs.
94
+
- Label screenshots clearly in your PR description.
95
+
96
+
- **Runner:**
97
+
- Provide the testing setup. For example, the agent definition, and the runner setup.
98
+
- Execute the `runner` tool to reproduce workflows.
99
+
- Include the command used and console output showing test results.
100
+
- Highlight sections of the log that directly relate to your change.
101
+
102
+
## Documentation
103
+
104
+
For any changes that impact user-facing documentation (guides, API reference, tutorials), please open a PR in the [adk-docs](https://github.com/google/adk-docs) repository to update relevant part before or alongside your code PR.
105
+
106
+
## Code reviews
71
107
72
108
All submissions, including submissions by project members, require review. We
73
109
use GitHub pull requests for this purpose. Consult
0 commit comments