android-testing-unit
Write fast, focused Android unit tests for reducers, use cases, repositories, and lifecycle-safe state holders.
55
45%
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-testing-unit/SKILL.mdQuality
Discovery
67%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description is strong in specificity and distinctiveness, clearly naming the domain (Android unit testing) and the specific architectural components targeted. Its main weaknesses are the absence of an explicit 'Use when...' clause and missing some common trigger term variations that users might naturally use when requesting help with Android testing.
Suggestions
Add a 'Use when...' clause, e.g., 'Use when the user asks to write or improve unit tests for Android architecture components like reducers, use cases, repositories, or ViewModels.'
Include additional natural trigger terms such as 'JUnit', 'Mockk', 'ViewModel', 'TDD', 'test coverage', or 'Android testing' to improve discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions and targets: 'Write fast, focused Android unit tests for reducers, use cases, repositories, and lifecycle-safe state holders.' This names the action (write unit tests) and enumerates specific components being tested. | 3 / 3 |
Completeness | Clearly answers 'what' (write fast, focused Android unit tests for specific components) but lacks an explicit 'Use when...' clause or equivalent trigger guidance, which caps this at 2 per the rubric guidelines. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'Android unit tests', 'reducers', 'use cases', 'repositories', and 'lifecycle-safe state holders', which are natural for Android developers. However, it misses common variations like 'testing', 'ViewModel', 'JUnit', 'Mockk', 'test coverage', or 'TDD' that users might naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | Highly specific niche: Android unit tests for a particular set of architectural components (reducers, use cases, repositories, lifecycle-safe state holders). This is unlikely to conflict with general testing skills or other Android skills due to the precise scope. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
22%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill fails at its stated purpose: teaching Claude to write Android unit tests for reducers, use cases, repositories, and lifecycle-safe state holders. It contains no executable test code, no concrete patterns, and no specific guidance—just generic quality-engineering platitudes and gradle commands to run pre-existing tests. The workflow section reads like a reusable template that was never customized for this skill's domain.
Suggestions
Add concrete, executable test code examples for each target (reducer test with JUnit, repository test with mocked data source, use case test with coroutines/Turbine) showing imports, setup, assertions, and expected output.
Replace the generic 5-step workflow with an Android-unit-test-specific workflow: identify the class under test → set up test dependencies (MockK/fake) → write test cases covering happy path, error, and edge cases → run and verify → check coverage.
Remove or heavily condense the generic Guardrails and Anti-Patterns sections, replacing them with Android-testing-specific pitfalls (e.g., testing implementation details of ViewModel instead of state emissions, not using TestDispatcher for coroutines).
Add inline code snippets showing patterns like testing a MVI reducer's state transitions, mocking a repository with MockK, or using Turbine to test Flow emissions from a ViewModel.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is moderately efficient but includes generic filler sections (Guardrails, Anti-Patterns) that read like boilerplate rather than Android-unit-test-specific guidance. Phrases like 'Treat performance and security work as engineering tasks with evidence, not folklore' waste tokens on platitudes Claude already knows. | 2 / 3 |
Actionability | Despite claiming to teach how to write unit tests for reducers, use cases, repositories, and state holders, the skill provides zero executable test code, no test structure examples, no assertion patterns, and no concrete guidance on mocking or test setup. The examples section only shows gradle commands to run existing tests, not how to write them. | 1 / 3 |
Workflow Clarity | The workflow is entirely abstract and generic ('Scope the risk surface', 'Pick the narrowest verification strategy') with no Android-testing-specific steps. There are no validation checkpoints, no feedback loops for test failures, and no concrete sequence for writing a unit test for a reducer or repository. | 1 / 3 |
Progressive Disclosure | The skill mentions handoff skills (android-testing-ui, android-ui-states-validation) and includes official references, which is good structure. However, the main content itself is a wall of generic text with no references to detailed companion files for specific patterns like reducer testing or repository mocking. | 2 / 3 |
Total | 6 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
metadata_field | 'metadata' should map string keys to string values | Warning |
Total | 10 / 11 Passed | |
- Repository
- krutikJain/android-agent-skills
- Commit
c5bf673
- Reviewed
Table of Contents
Is this your skill?
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.