Write Unit Tests, UI Tests (Compose), and Hilt-integrated tests for Android. Use whenever writing Android test files or asking about runTest, composeTestRule, HiltAndroidRule, MockK, MainDispatcherRule, @TestInstallIn, or how to test a ViewModel/Composable/Repository in Android. (triggers: **/*Test.kt, **/*Rule.kt, @Test, runTest, composeTestRule, HiltAndroidTest, MockK, createAndroidComposeRule, MainDispatcherRule, @TestInstallIn)
75
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./skills/android/android-testing/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly defines its scope (Android testing), lists specific concrete actions, and provides comprehensive trigger terms covering both natural language queries and file patterns. The explicit 'Use whenever...' clause with detailed trigger scenarios makes it easy for Claude to know exactly when to select this skill. The parenthetical triggers list adds further precision for file-pattern matching.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: 'Write Unit Tests, UI Tests (Compose), and Hilt-integrated tests for Android.' It names specific test types (unit, UI/Compose, Hilt-integrated) and the platform (Android). | 3 / 3 |
Completeness | Clearly answers both 'what' (write unit tests, UI tests, Hilt-integrated tests for Android) and 'when' (explicit 'Use whenever writing Android test files or asking about...' clause with specific trigger scenarios and file patterns). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms users would say: runTest, composeTestRule, HiltAndroidRule, MockK, MainDispatcherRule, @TestInstallIn, ViewModel, Composable, Repository, plus file patterns like **/*Test.kt. These are terms Android developers naturally use when asking about testing. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with a clear niche: Android-specific testing with named frameworks (Compose, Hilt, MockK). The specific trigger terms like HiltAndroidTest, composeTestRule, and MainDispatcherRule are unique to this domain and unlikely to conflict with other skills. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
37%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is admirably concise and well-structured at a high level, but it critically lacks actionability—there are zero code examples for any of the testing patterns mentioned (ViewModel tests, Compose UI tests, Hilt-integrated tests). The content reads more like a table of contents or checklist than an instructional skill. Without executable examples and a clear workflow, Claude would struggle to produce correct, idiomatic Android test code from this alone.
Suggestions
Add at least one complete, executable code example for each test type (Unit Test with runTest/MockK, UI Test with createAndroidComposeRule/HiltAndroidRule) showing imports, rule setup, and assertions.
Include a step-by-step workflow for writing a test: e.g., 1) Create test class with annotations, 2) Set up rules, 3) Mock dependencies, 4) Write test method, 5) Run and verify.
Add a concrete MainDispatcherRule implementation example and show how it's used in a ViewModel test, since this is a common pain point.
Show a concrete @TestInstallIn example with a fake repository module to make the DI isolation guidance actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Very lean and efficient. No unnecessary explanations of what unit tests are, what Hilt is, or how Android works. Every line adds value and assumes Claude's competence with Android development. | 3 / 3 |
Actionability | No executable code examples whatsoever. The content describes what to use (runTest, MockK, createAndroidComposeRule) but never shows how. There are no concrete code snippets, no copy-paste ready test examples, and no specific commands—just abstract bullet points. | 1 / 3 |
Workflow Clarity | There is no sequenced workflow for writing tests. The content lists tools and anti-patterns but doesn't guide Claude through the steps of creating a test file, setting up rules, writing assertions, or running/validating tests. | 1 / 3 |
Progressive Disclosure | There is a reference to an implementation.md file for test rules, which is good. However, the main content is too sparse to serve as a useful overview—it lacks enough substance to stand on its own, and only one reference is provided without clear signaling of what additional content exists there. | 2 / 3 |
Total | 7 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
19a1140
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.