Add Android testing skill for Claude #6370
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6370 +/- ##
=======================================
Coverage 85.77% 85.77%
=======================================
Files 775 775
Lines 56203 56203
Branches 8123 8123
=======================================
Hits 48207 48207
Misses 5172 5172
Partials 2824 2824 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Great job! No new security vulnerabilities introduced in this pull request |
SaintPatrck
force-pushed
the
claude/testing-android-code-skill
branch
3 times, most recently
from
ebe7698 to
f83fdfc
Compare
This commit introduces a new Claude skill named `testing-android-code` to provide comprehensive guidance and standardized patterns for writing tests within the Bitwarden Android codebase.
The primary objective is to codify best practices and provide developers with quick access to reference documentation, examples, and common pitfalls, thereby improving test quality, consistency, and development efficiency.
The skill is composed of the following documents:
- A main `SKILL.md` file that serves as a quick-reference guide, outlining key patterns for testing ViewModels, Compose UIs, Repositories, and Services. It also introduces test data builders and utility classes.
- A `README.md` explaining the purpose and contents of the skill.
- Detailed reference documents for:
- `test-base-classes.md`: Explains the usage of `BaseViewModelTest`, `BitwardenComposeTest`, and `BaseServiceTest`.
- `flow-testing-patterns.md`: Details how to test StateFlow and EventFlow using Turbine, highlighting the critical differences in their testing patterns.
- `critical-gotchas.md`: Lists common antipatterns and mistakes, such as misusing `assertCoroutineThrows` with `runTest` and forgetting to unmock static functions.
- Complete, copy-pasteable examples for testing major components:
- `viewmodel-test-example.md`
- `compose-screen-test-example.md`
- `repository-test-example.md`
SaintPatrck
force-pushed
the
claude/testing-android-code-skill
branch
from
f83fdfc to
db99690
Compare
|
https://bitwarden.slack.com/archives/C09MHQNCSKD/p1769693094966979 -- is this a skill or a prompt? And do we think this will move to the marketplace in time or is so specific it will just be here? I am thinking about the reviewer agent benefitting. |
|
@withinfocus it's a Skill, although I'm toying with the idea of making it a Rule once I've had a chance to tinker with them. I keep going back-and-forth on moving it to the marketplace or keeping it here given it's so specialized. My main hesitation is the friction it may introduce for maintenance. If we consider it a living document to update as we fine-tune Claude for this repo, I would prefer it reside here. I feel like that will encourage and facilitate faster iterations. The reviewer agent, and the implementor/developer agent being built, will inherently have access to this as long as they're initiated in the repo root. If we move it to the marketplace the plugin has to be manually installed everywhere. There may be ways to configure the repo to automagically install the marketplace+plugin, but I've not looked into that approach thoroughly. For the sake of getting something started I think it's best we begin with it here, iterate a bit until the team is confident with it, then promote it to the marketplace if there's a larger desire/need to do so. Edit: |
| } | ||
|
|
||
| companion object { | ||
| private val DEFAULT_STATE = ExampleState( |
There was a problem hiding this comment.
Can we move this out of the companion object and just have it be at the top-level of the file?
| } | ||
|
|
||
| // Default state for assertions - always define complete expected states | ||
| private val defaultState = ExampleState( |
There was a problem hiding this comment.
Stuff like this is usually top-level
| private fun createViewModel( | ||
| initialState: ExampleState? = null, | ||
| ): ExampleViewModel = ExampleViewModel( | ||
| savedStateHandle = SavedStateHandle().apply { set("state", initialState) }, |
Moves the `DEFAULT_STATE` constant from a class-level property to a top-level private val in both `viewmodel-test-example.md` and `compose-screen-test-example.md`. This change improves consistency and cleans up the test class structure by removing the `companion object` in the Compose test example.
|
Claude finished @SaintPatrck's task in 1m 38s —— View job Code Review SummaryPR: Add Android testing skill for Claude OverviewThis PR introduces a comprehensive Claude skill for testing Android code in the Bitwarden codebase. The skill provides tactical testing guidance including base class documentation, flow testing patterns, and common anti-patterns. Files Reviewed
Verification
AssessmentNo issues found. This is a well-organized documentation skill that:
Automated review by Claude |
🎟️ Tracking
TBD
📔 Objective
Introduce a new Claude skill named
testing-android-codeto provide comprehensive guidance and standardized patterns for writing tests within the Bitwarden Android codebase.The primary objective is to codify best practices and provide Claude with quick access to reference documentation, examples, and common pitfalls, thereby improving test quality, consistency, and development efficiency.
The skill is composed of the following documents:
SKILL.mdfile that serves as a quick-reference guide, outlining key patterns for testing ViewModels, Compose UIs, Repositories, and Services. It also introduces test data builders and utility classes.README.mdexplaining the purpose and contents of the skill.test-base-classes.md: Explains the usage ofBaseViewModelTest,BitwardenComposeTest, andBaseServiceTest.flow-testing-patterns.md: Details how to test StateFlow and EventFlow using Turbine, highlighting the critical differences in their testing patterns.critical-gotchas.md: Lists common antipatterns and mistakes, such as misusingassertCoroutineThrowswithrunTestand forgetting to unmock static functions.viewmodel-test-example.mdcompose-screen-test-example.mdrepository-test-example.md⏰ Reminders before review
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes