Senior QA
nicepkg/auto-company
Comprehensive QA and testing skill for quality assurance, test automation, and testing strategies for ReactJS, NextJS, NodeJS applications.
A skill your agent uses to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid.
Install Understanding The Testing Pyramid
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramid --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .claude/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .claude/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramidType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramid --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .agents/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .agents/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .agents/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramid --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .cursor/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .cursor/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/skydoves/android-testing-skills.git --path fundamentals/concepts/understanding-the-testing-pyramid--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramid --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .gemini/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .gemini/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramidInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .github/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .github/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .github/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install skydoves/android-testing-skills understanding-the-testing-pyramid --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/skydoves/android-testing-skills.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/fundamentals/concepts/understanding-the-testing-pyramid .opencode/skills/understanding-the-testing-pyramid && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "understanding-the-testing-pyramid" agent skill from https://github.com/skydoves/android-testing-skills/tree/main/fundamentals/concepts/understanding-the-testing-pyramid into .opencode/skills/understanding-the-testing-pyramid/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "understanding-the-testing-pyramid", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
understanding-the-testing-pyramid- GitHub stars
- 333
- Token cost
- ~4.4k tokens
- SKILL.md length
- 1,736 words
- Files
- 1
- Skills in repo
- 50
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
A skill your agent uses to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid.
- Works in 4 steps: The product IS the integration. A… → The framework owns the logic. A pure… → Determinism is the point. A… → …
- Size an Android test suite using Googles small / medium / big scope vocabulary and the qualitative pyramid
- SKILL.md covers When to use this skill, When NOT to use this skill, Prerequisites and The two framings (pick exactly…, plus 10 more sections
- Reaches abseil.io
What it does
Understanding The Testing Pyramid is an agent skill from skydoves/android-testing-skills. Use this skill to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid. Explains why most apps should hold "many small tests and relatively few big tests", how scope (small/medium/big) is orthogonal to execution location (local vs instrumented), and where the older 70/20/10 numeric ratio actually comes from. Use when the user asks "how many unit vs UI tests should I write", "what's the testing pyramid", "all my tests are instrumented and CI is slow", "test…
Its SKILL.md is about 4.4k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.
It sits in Testing & QA, covering Test generation and Test strategy. It works with Android. The repository describes itself as: ⚡️ A set of skills for Android testing: Compose UI, AndroidX Test, JVM unit tests, and ADB. The licence is Apache-2.0.
When your agent uses it
- Size an Android test suite using Googles small / medium / big scope vocabulary and the qualitative pyramid
- The user asks how many unit vs UI tests should I write
- Whats the testing pyramid
- All my tests are instrumented and CI is slow
Example prompts
- “many small tests and relatively few big tests”
- “how many unit vs UI tests should I write”
- “s the testing pyramid”
- “/understanding-the-testing-pyramid”
Workflow steps
4 steps, taken from the first numbered list in SKILL.md.
- The product IS the integration. A payments SDK that primarily wires three vendor SDKs together has more value in feature/application tests…
- The framework owns the logic. A pure CRUD screen with a DataStore-backed ViewModel and stock Material widgets has very little to…
- Determinism is the point. A render-correctness suite (screenshot tests, animation timing) lives at the big-test layer because that is…
- Cost economics flip. On Firebase Test Lab / Gradle Managed Devices the per-minute cost of a big test may be small enough that the…
What it can do on your machine
Read from SKILL.md and the folder at commit 8665ed5. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
No scripts in the folder and no shell commands in SKILL.md (its code samples are markdown).
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
abseil.io
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Understanding The Testing Pyramid loads about 4.4k tokens when it runs. Until then it costs about 187 tokens; SKILL.md has 1,736 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from skydoves/android-testing-skills at commit 8665ed5, republished under its Apache-2.0 licence (© skydoves). 1,736 words, ~4,368 tokens.
Download SKILL.mdSave it as
.claude/skills/understanding-the-testing-pyramid/SKILL.md (or your agent's skills folder).- name
- understanding-the-testing-pyramid
- description
- Use this skill to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid. Explains why most apps should hold "many small tests and relatively few big tests", how scope (small/medium/big) is orthogonal to execution location (local vs instrumented), and where the older 70/20/10 numeric ratio actually comes from. Use when the user asks "how many unit vs UI tests should I write", "what's the testing pyramid", "all my tests are instrumented and CI is slow", "test pyramid 70 20 10", "Android small medium large tests", "Robolectric counts as which layer", or mentions Unit / Component / Feature / Application / Release Candidate framing from the strategies page.
- license
- Apache-2.0. See LICENSE for complete terms.
- metadata.author
- Jaewoong Eum (skydoves)
- metadata.keywords
- android-testing, testing-pyramid, test-scope, small-medium-big, test-strategy, flaky-tests, ci-slow, instrumented-vs-local, robolectric, junit4
Understanding the Testing Pyramid — Pick the 3-Layer Framing and Stick to It
Android test suites slow CI and rot when teams ship one big instrumented test per behavior and skip unit coverage of the underlying logic. Google's /training/testing/fundamentals page frames test sizing with three scopes — small, medium, big — and the /strategies page sketches a qualitative pyramid on top of that. This skill encodes the 3-layer framing, names the alternative 5-layer framing so authors do not blend them, and is honest about where the famous numeric ratios come from. Subsequent skills (../choosing-what-to-test/SKILL.md, ../../strategies/applying-testing-strategies/SKILL.md) assume this vocabulary.
When to use this skill
- The user asks "how many unit vs UI tests should I write" or quotes a 70/20/10 / 80/15/5 ratio and asks if it is in Google's docs.
- The user calls every test "an integration test" / "an end-to-end test" and the agent needs a vocabulary to sort them.
- The user reports "CI is slow" / "the suite takes 40 minutes" and wants to know whether to delete instrumented tests.
- The user asks whether Robolectric is "a unit test" or "an integration test" — it is a medium-local test in Google's framing.
- The user is starting a new module and asks where to begin (answer: small tests first, per
/strategies).
When NOT to use this skill
- The user wants to know what to put in each test (which screens, which ViewModels) — use
../choosing-what-to-test/SKILL.md. - The user wants to wire
testImplementationvsandroidTestImplementationGradle configurations — use../../strategies/organizing-test-source-sets/SKILL.md. - The user wants to pick between
Fake/Mock/Stub/Spy— use../../doubles/picking-test-doubles/SKILL.md. - The user is debugging a single flaky test and wants to fix it — start with
../../../compose/synchronization/synchronizing-with-idle/SKILL.mdor../../../jvm-tests/coroutines/testing-coroutines-with-runtest/SKILL.md.
Prerequisites
- A module with at least one test class so the discussion is concrete.
- Familiarity with the
src/test/(local, JVM) andsrc/androidTest/(instrumented) split. If unfamiliar, read../../strategies/organizing-test-source-sets/SKILL.mdfirst. - An understanding that "scope" (small/medium/big) and "execution location" (local/instrumented) are two independent axes per Google.
The two framings (pick exactly one per skill / per design doc)
Google publishes two framings on adjacent pages. They are not contradictory; they are different views.
Framing A — Small / Medium / Big (3 layers) ← this skill recommends this one
From /training/testing/fundamentals ("Types of tests in Android" → "By Scope"):
"Tests are also classified by their scope, or how much of the code they cover. There are three categories of test scope:
- Unit tests or small tests only verify a very small portion of the app, such as a method or class.
- End-to-end tests or big tests verify larger parts of the app at the same time, such as a whole screen or user flow.
- Medium tests are in between and check the integration between two or more units." —
developer.android.com/training/testing/fundamentals
| Scope | What it covers | Typical runner | Typical execution |
|---|---|---|---|
| Small | One method or class | JUnit4 + Mockito/MockK + fakes | src/test/ (JVM) |
| Medium | 2+ classes integrating, possibly Android framework via Robolectric | JUnit4 + Robolectric or in-process Android | src/test/ (host) OR src/androidTest/ (instrumented) |
| Big | A whole screen, user flow, or release-build smoke | AndroidJUnitRunner + Espresso/Compose-test/UiAutomator | src/androidTest/ |
Framing B — Unit / Component / Feature / Application / Release Candidate (5 layers)
From /training/testing/fundamentals/strategies (the "scalable strategy" table):
| Level | Scope | Network |
|---|---|---|
| Unit | Single method or class with minimal dependencies | None |
| Component | Module or component | None |
| Feature | Multiple components / modules | "supports mocked network access" |
| Application | Whole app, debuggable binary | n/a |
| Release Candidate | Whole release build, minified | n/a |
Most teams stay with the 3-layer Framing A because it is the simpler, more cited shape. Reach for Framing B only when designing a multi-team CI strategy where the extra granularity earns its keep. MUST NOT blend the two in a single doc — pick one and stick with it.
Scope is orthogonal to execution location
The single most important quote on the page, and the one the agent should cite when a developer says "all my tests are instrumented":
"Not all unit tests are local, and not all end-to-end tests run on a device. For example:
- Big local test: You can use an Android simulator that runs locally, such as Robolectric.
- Small instrumented test: You can verify that your code works well with a framework feature, such as a SQLite database." —
developer.android.com/training/testing/fundamentals
Two axes:
LOCAL (JVM) INSTRUMENTED (device)
SMALL pure JUnit + fakes unit test of SQLite via real DB
MEDIUM Robolectric component component test on real Android
BIG Robolectric flow Espresso / Compose UI flowRobolectric is a local Android simulator. It is not "an instrumented test" — it runs on the JVM under src/test/. See ../../strategies/organizing-test-source-sets/SKILL.md and the cross-category skill ../../../jvm-tests/robolectric/using-robolectric-correctly/SKILL.md.
The qualitative pyramid
The /strategies page only commits to a qualitative shape:
"Most apps should have many small tests and relatively few big tests, forming a pyramid shape." —
developer.android.com/training/testing/fundamentals/strategies
"Key Point: In general, you should try to add tests as soon as possible in the development cycle. That typically means starting with small tests." —
developer.android.com/training/testing/fundamentals/strategies
That is the entirety of Google's current quantitative claim: "many small, few big". No ratio.
Where the 70/20/10 ratio actually comes from
The "70 percent unit, 20 percent integration, 10 percent end-to-end" rule is widely cited but is NOT present on the current /training/testing/fundamentals or /training/testing/fundamentals/strategies pages (as of 2026-05-06; verified in tasks/research/R8-android-fundamentals.md). The number is from Google's own engineering literature — Software Engineering at Google, chapter 11 — not the Android training pages.
MUST NOT attribute "70/20/10" to developer.android.com. The numeric ratio is a community heuristic popularised in Software Engineering at Google (https://abseil.io/resources/swe-book, ch. 11) — paraphrase carefully, do NOT present any specific sentence as a verbatim quote unless you confirm it line-by-line in the book. The book frames the split as a heuristic, not a law: different domains warrant different ratios; see "When to break the pyramid" below.
Cost / speed tradeoff
The reason the pyramid bottom is wide:
| Layer | Wall-clock per test | Failure signal | Maintenance cost |
|---|---|---|---|
| Small | 1-50 ms | Pinpoints a class/method | Low |
| Medium (Robolectric) | 50-500 ms | Pinpoints a component | Medium |
| Big (instrumented) | 5-30 s | Says "the screen is broken" | High (flake, emulator state, animation) |
A flat or inverted pyramid (lots of big tests, few small) produces:
- Slow CI (10x to 100x slower than a unit-heavy suite of equivalent coverage).
- High flake rate; flake correlates with test size and external dependencies (
/strategiesnotes "no network access" for unit and component layers). - Vague failure signal — "screen X broken" instead of "function Y returned the wrong value for input Z".
- Painful refactors — UI tests assert on rendered text and break on every copy change.
/training/testing/instrumented-tests makes the price explicit:
"We recommend using instrumented tests only in cases where you must test against the behavior of a real device." —
developer.android.com/training/testing/instrumented-tests
That is Google's "use big tests as a last resort" stance, in their own words.
Show full SKILL.md (676 more words)Show less
When to break the pyramid intentionally
The pyramid is a default, not a law. Break it when:
- The product IS the integration. A payments SDK that primarily wires three vendor SDKs together has more value in feature/application tests than in unit tests of glue code. The unit tests would be tautological mock verifications.
- The framework owns the logic. A pure CRUD screen with a DataStore-backed
ViewModeland stock Material widgets has very little to unit-test. Big tests catch wiring; small tests would just be testingrunBlocking { dataStore.data.first() }. - Determinism is the point. A render-correctness suite (screenshot tests, animation timing) lives at the big-test layer because that is where the bug surfaces. See the cross-category skill
../../../compose/audit/auditing-compose-test-suite/SKILL.md. - Cost economics flip. On Firebase Test Lab / Gradle Managed Devices the per-minute cost of a big test may be small enough that the maintenance cost dominates anyway — and unit tests still win on flake.
What does NOT justify breaking the pyramid:
- "Unit tests are too hard to set up" — that is a signal of bad architecture, not a reason to pile on big tests. See
developer.android.com/training/testing/fundamentals("With a testable app architecture …"). - "We can't mock X" — use a fake instead of a mock. See
../../doubles/picking-test-doubles/SKILL.md. - "It works on my machine, just ship more device tests" — the flake will follow the suite. Diagnose with
../../../adb/observability/extracting-logs-with-logcat/SKILL.md.
Patterns
Pattern: WRONG vs RIGHT — citing the 70/20/10 ratio
<!-- WRONG -->
> Per Google's developer documentation, the testing pyramid recommends
> a 70/20/10 split between unit, integration, and end-to-end tests.
> Source: developer.android.com/training/testing/fundamentals/strategiesWRONG because: that ratio is not on the strategies page as of 2026-05-06. The page only says "many small, few big" qualitatively. Citing developer.android.com here is fabrication.
<!-- RIGHT -->
> Google's Android docs commit to a qualitative pyramid only:
> "Most apps should have many small tests and relatively few big tests"
> (developer.android.com/training/testing/fundamentals/strategies).
> The familiar 70/20/10 split comes from Software Engineering at Google,
> ch. 11 (https://abseil.io/resources/swe-book), not the Android docs.Pattern: WRONG vs RIGHT — labeling Robolectric
<!-- WRONG -->
> Robolectric tests are instrumented tests because they exercise the
> Android framework. Put them in src/androidTest/.WRONG because: Robolectric runs on the JVM with no Android device or emulator. Per /training/testing/fundamentals ("Big local test: You can use an Android simulator that runs locally, such as Robolectric"), Robolectric is a local test, in src/test/, regardless of scope.
<!-- RIGHT -->
> Robolectric is a local (JVM) Android simulator. By scope it can be small,
> medium, or big depending on what the test exercises. Place it in src/test/.
> Use src/androidTest/ only for tests that require a real device.Pattern: WRONG vs RIGHT — pyramid framing in one design doc
<!-- WRONG -->
> Our suite has 200 small tests, 40 medium tests, 8 feature tests, and
> 3 release-candidate tests, which is a healthy pyramid.WRONG because: this blends Framing A ("small/medium") with Framing B ("feature/release candidate"). The reader cannot tell whether "small" means Framing A's small or Framing B's unit.
<!-- RIGHT — pick Framing A and stick with it -->
> Our suite has 200 small tests, 40 medium (Robolectric component) tests,
> and 11 big (instrumented Compose-test + Espresso) tests. Per Google's
> small/medium/big framing on /training/testing/fundamentals, the ratio
> is roughly 80/16/4, in line with the pyramid recommendation.Decision matrix — what scope should a new test be?
Question → Scope
----------------------------------------------------------
"Does it depend on the Android framework?"
No → Small (src/test/)
Yes, simulated via Robolectric → Medium (src/test/)
Yes, must be a real device → Big (src/androidTest/)
"Does it exercise more than one class?"
No → Small
Yes, but no I/O / no UI → Medium
Yes, with UI rendering or system services → Big
"Does it cross a network or process boundary?"
No → Small or Medium
Yes (mocked) → Medium (Feature in Framing B)
Yes (real) → Big (Application/RC in Framing B)Mandatory rules
- MUST use the 3-layer "small / medium / big" framing in default skill copy and design docs. Reach for the 5-layer Unit/Component/Feature/Application/Release Candidate framing only when explicitly invoking the
/strategiespage. - MUST NOT blend the two framings in a single document. Pick one.
- MUST NOT attribute the "70/20/10" numeric ratio to
developer.android.com. Cite Software Engineering at Google (https://abseil.io/resources/swe-book). - MUST NOT describe Robolectric as "an instrumented test". It is a local Android simulator that may carry any scope.
- MUST label every new test with its scope in a comment or naming convention (
@SmallTest,@MediumTest,@LargeTestfromandroidx.test.filters) so CI can shard accordingly. - PREFERRED: start a new module with small tests first, per Google's "starting with small tests" guidance, and only add medium/big tests where small ones cannot reach.
- PREFERRED: when CI is slow, delete redundant big tests before adding more small ones — the pyramid tightens by removing the top, not just by widening the base.
Verification
- Every test class in the module is reachable via one of
@SmallTest,@MediumTest,@LargeTest(or by source-set placement). - No test in
src/androidTest/could equivalently run as a Robolectric host test insrc/test/without losing fidelity. (If yes, move it.) - CI logs report unit-test wall time < instrumented-test wall time per layer per change.
- No design doc cites "70/20/10" attributed to
developer.android.com. - No design doc blends Framing A and Framing B vocabulary.
- The team's testing strategy doc names exactly one framing in its glossary.
References
developer.android.com/training/testing/fundamentals— small/medium/big scope, "Not all unit tests are local" quote, testable architecture rationale.developer.android.com/training/testing/fundamentals/strategies— qualitative pyramid ("many small, few big"), 5-level Unit/Component/Feature/Application/Release Candidate table, "starting with small tests" guidance.developer.android.com/training/testing/instrumented-tests— "instrumented tests only in cases where you must test against the behavior of a real device".- Software Engineering at Google, ch. 11 — origin of the 70/20/10 ratio. https://abseil.io/resources/swe-book
tasks/research/R8-android-fundamentals.md— verbatim quotes, version-sensitive notes, the "70/20/10 not on the page" finding.androidx.test.filters—@SmallTest/@MediumTest/@LargeTestannotations for runtime sharding.- Sibling skills:
../choosing-what-to-test/SKILL.md,../../doubles/picking-test-doubles/SKILL.md,../../strategies/applying-testing-strategies/SKILL.md,../../strategies/organizing-test-source-sets/SKILL.md. - Cross-category:
../../../jvm-tests/robolectric/using-robolectric-correctly/SKILL.md,../../../jvm-tests/runner/configuring-junit4-on-android/SKILL.md,../../../instrumentation/runner/running-instrumented-tests-with-androidjunit4/SKILL.md,../../../compose/audit/auditing-compose-test-suite/SKILL.md.
© skydoves, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in fundamentals/concepts/understanding-the-testing-pyramid of skydoves/android-testing-skills.
Open the folder on GitHubat commit 8665ed5
Compare with similar skills
Understanding The Testing Pyramid next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Understanding The Testing Pyramid this skillskydoves/android-testing-skills | 333 | — | ~4.4k | Automated safety check: Pass | Apache-2.0 | |
| Senior QAnicepkg/auto-company | 194 | 3 repos | ~1.1k | Automated safety check: Notes | None | |
| Kane CLI Browser TestingLambdaTest/kane-cli | 248 | — | ~8.4k | Automated safety check: Pass | Apache-2.0 | |
| QA Manual Istqbfugazi/test-automation-skills-agents | 247 | — | ~3.6k | Automated safety check: Pass | MIT | |
| QAdutradotdev/quokka | 108 | — | ~1k | Automated safety check: Pass | MIT | |
| Test RoadmapOvid/paad | 131 | — | ~2.3k | Automated safety check: Pass | MIT |
Similar skills
Kane CLI Browser Testing
LambdaTest/kane-cli
Drives a real browser through the kane-cli tool and designs requirement-linked test suites from a PRD or a plain description, with mobile and cloud-grid runs.
QA Manual Istqb
fugazi/test-automation-skills-agents
Create QA artifacts from requirements: test plans, test conditions/cases, bug reports, regression suites, traceability, and exploratory charters.
QA
dutradotdev/quokka
Run quokka's real-device E2E layer (QA strategy layer 5): drive the real qk binary against connected iPhone/Android devices through tmux, apply deterministic verifiers, and write a report.
Test Roadmap
Ovid/paad
EXPERIMENTAL. An agent skill from Ovid/paad.
Designing Tests
CloudAI-X/opencode-workflow
Guides test strategy, TDD/BDD approaches, test coverage planning, and testing best practices.
More from skydoves/android-testing-skills
All 50 skills in this repoAsserting Bounds And Dimensions
skydoves/android-testing-skills
A skill your agent uses to verify Compose layout measurements from a UI test using assertWidthIsEqualTo, assertHeightIsEqualTo, assertWidthIsAtLeast, assertHeightIsAtLeast…
Asserting Node State And Text
skydoves/android-testing-skills
A skill your agent uses to verify a Compose semantics node's properties from a UI test using assertExists, assertDoesNotExist, assertIsDisplayed, assertIsNotDisplayed, assertIsDeactivated…
Capturing Preview Screenshots In CI
skydoves/android-testing-skills
A skill your agent uses to render every Jetpack Compose @Preview as a screenshot on a real Android device or emulator and publish a browsable HTML catalog from CI.
Capturing Screenshots And Screenrecord
skydoves/android-testing-skills
A skill your agent uses to capture visual artefacts from a device for test failures, golden image generation, QA repro, and demo videos.
Choosing Test Rule Vs Runtest
skydoves/android-testing-skills
A skill your agent uses to pick the correct Compose UI test entry point.
Choosing What To Test
skydoves/android-testing-skills
A skill your agent uses to pick which behaviors to cover in an Android test suite using Google's five-category state vocabulary plus the explicit "what NOT to test" list from…
Related
Works with
Categories
Questions about Understanding The Testing Pyramid
What does Understanding The Testing Pyramid do?
A skill your agent uses to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid. Understanding The Testing Pyramid is an agent skill from skydoves/android-testing-skills. Use this skill to size an Android test suite using Google's small / medium / big scope vocabulary and the qualitative pyramid.
When should I use Understanding The Testing Pyramid?
Understanding The Testing Pyramid fits situations like: size an Android test suite using Googles small / medium / big scope vocabulary and the qualitative pyramid; the user asks how many unit vs UI tests should I write; whats the testing pyramid; all my tests are instrumented and CI is slow.
How do I install Understanding The Testing Pyramid in Claude Code?
Run `npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a claude-code`. Or copy the skill folder (fundamentals/concepts/understanding-the-testing-pyramid in skydoves/android-testing-skills) into .claude/skills/understanding-the-testing-pyramid in your project. Claude Code loads it when a task matches its description.
How do I install Understanding The Testing Pyramid in Codex?
Run `npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a codex`. Or copy the skill folder (fundamentals/concepts/understanding-the-testing-pyramid in skydoves/android-testing-skills) into .agents/skills/understanding-the-testing-pyramid in your project. Codex loads it when a task matches its description.
Can I use Understanding The Testing Pyramid in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add skydoves/android-testing-skills --skill understanding-the-testing-pyramid -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/understanding-the-testing-pyramid, .gemini/skills/understanding-the-testing-pyramid, .github/skills/understanding-the-testing-pyramid and .opencode/skills/understanding-the-testing-pyramid in your project.
What does Understanding The Testing Pyramid need to run?
SKILL.md names no scripts, command-line tools or credentials: Understanding The Testing Pyramid is instructions for the agent only.
Does Understanding The Testing Pyramid access the network?
SKILL.md names 1 domain. In commands or code: abseil.io; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.
Is Understanding The Testing Pyramid safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Understanding The Testing Pyramid use?
Understanding The Testing Pyramid is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Understanding The Testing Pyramid use?
About 4.4k tokens (SKILL.md is roughly 17k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Understanding The Testing Pyramid?
Skills that share tags, products or a category with Understanding The Testing Pyramid: Senior QA (nicepkg/auto-company, 194 stars), Kane CLI Browser Testing (LambdaTest/kane-cli, 248 stars), QA Manual Istqb (fugazi/test-automation-skills-agents, 247 stars) and QA (dutradotdev/quokka, 108 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Understanding The Testing Pyramid?
skydoves (a GitHub user) maintains it in skydoves/android-testing-skills, which has 333 GitHub stars. The repository holds 50 skills in this directory. The repository was last updated on May 25, 2026.
Source: skydoves/android-testing-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.