菜单
Use when the user asks to write tests for mobile code, or after applying a fix that needs regression tests.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/ArisGuimera/MobiAI-Core --skill mobiai-write-tests命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | mobiai-write-tests |
| description | Use when the user asks to write tests for mobile code, or after applying a fix that needs regression tests. |
| license | MIT |
| compatibility | ["claude-code","cursor","copilot","codex"] |
| platforms | ["android","ios","kmp","flutter","react-native"] |
Write tests that cover a bug fix or new feature, following the project's existing patterns and platform conventions.
mobiai-fix-issue pipelineNote: If you're implementing a new feature or fix from scratch, consider using mobiai-mobile-tdd instead — it enforces writing tests FIRST (Red-Green-Refactor). This skill is for adding tests to existing code.
Standalone invocations only — skip this section when called from mobiai-fix-issue or mobiai-mobile-tdd, which run their own pre-flight or wrap this skill mid-flow.
If <repo>/.mobiai/brain/config.json exists, do a quick review pass before designing the test cases. A known workaround in the same area might shape what's worth asserting (the test should verify the workaround still works, not assume the fix is upstream).
Preferred — MCP tool (when mobiai-brain MCP server is registered):
Invoke mobile_review with default args. Focus on entries whose platform matches the project's platform and whose area overlaps with the system under test (datastore, networking, lifecycle, etc.). Run mobile_scan first if you don't already know the project's platform.
Fallback — CLI:
mobiai brain review --no-fail
If 1+ overdue entries match, mention them to the user before Step 1:
"Heads up — there are N overdue workaround(s) in / that may shape what these tests need to cover: . I'll proceed; let me know if you want to look at those first."
Then continue with Step 1. Skip silently when:
Standalone invocations only — skip this section when called from mobiai-fix-issue or mobiai-mobile-tdd, which run their own Graph pre-flight or wrap this skill mid-flow.
The Graph helps locate the system under test, its callers, and nearby existing tests — useful before Step 1 (Understand What to Test) and Step 2 (Find Existing Test Patterns).
If <repo>/.mobiai/graph/index.json exists:
# Freshness — if "hace Xd" with X ≥ 1, suggest refresh (don't auto-run):
mobiai graph status
# Locate the symbol being tested:
mobiai graph search <ClassOrFunctionUnderTest>
# See how it's used in the codebase (informs which test cases matter):
mobiai graph callers <ClassOrFunctionUnderTest>
# Find existing test classes nearby (informs patterns and naming):
mobiai graph search Test --kind class --limit 20
The callers list reveals which call sites depend on the behavior — those are the cases worth covering. The existing-test search shows the project's actual test conventions (framework, naming, location).
If the index is ≥1 day old:
"El índice del Graph es de hace Xd. Si querés resultados frescos, corré
mobiai graph init."
Don't run init autonomously.
If .mobiai/graph/index.json does not exist and the project has .kt or .swift files:
"No veo el índice del Graph. Generalo con
mobiai graph inity arranco — sin él tengo que descubrir las convenciones de tests grepeando."
Don't run init autonomously.
Skip silently when:
Before writing tests, find and read existing tests in the project:
Search for existing test files near the changed code:
**/test/**/*Test* or **/*_test.*class.*Test in test directoriesRead existing tests to understand:
Follow the project's existing patterns. If no patterns exist, follow platform defaults below.
Run the test suite to verify:
If tests fail, fix them. If existing tests fail and your fix caused the regression, fix that too.
Once tests pass, check whether <repo>/.mobiai/brain/config.json exists. If it does NOT, skip this step silently — not every project uses Brain.
If it does, decide whether this test is a reusable pattern worth saving as a testing_pattern entry. A test is worth saving when it captures a non-obvious mobile-specific gotcha — async/lifecycle timing, platform quirks, flaky-test workarounds, fixture patterns. Skip when the test is a routine assertion on business logic.
When it's worth saving, propose the save to the user first (one-line confirmation). Never invoke silently.
Preferred — MCP tool (if your client has the mobiai-brain MCP server registered, you'll see this tool in your toolbox):
Invoke mobile_save_testing with:
title: short pattern name, e.g. "DataStore clear waits for empty emission"platform: android | ios | shared | kmp | flutter | react-nativearea: free-form, e.g. "datastore" | "coroutines" | "xctest" | "maestro"files: array of repo-relative paths (test + system-under-test)body: Markdown with ### Problem / ### Solution / ### Example (omit ### Example when the language doesn't fit)Fallback — CLI (if MCP isn't configured):
mobiai brain save testing \
--title "<short pattern name, e.g. 'DataStore clear waits for empty emission'>" \
--platform <android|ios|shared|kmp|flutter|react-native> \
--area <free-form, e.g. datastore | coroutines | xctest | maestro> \
--files "<test_file>,<sut_file>" \
--body "### Problem
What goes wrong without this pattern (race, leak, false pass, etc.).
### Solution
The pattern itself, in one paragraph.
### Example
\`\`\`kotlin
// minimal code snippet
\`\`\`"
Skip the body's ### Example block on languages that don't fit. The fewer placeholders, the better — concrete pattern in the user's own words beats a generic template.
Default framework: JUnit 4 + MockK
Test location: Mirror source path under test directory
app/src/main/java/com/example/feature/MyClass.ktapp/src/test/java/com/example/feature/MyClassTest.ktNaming: Backtick-enclosed descriptive names
@Test
fun `calculateTotal returns zero when cart is empty`() { ... }
@Test
fun `formatPrice throws when amount is negative`() { ... }
Mocking: Use io.mockk (mockk, every, verify, coEvery for coroutines)
Coroutines: Use kotlinx-coroutines-test with runTest
Run tests:
./gradlew test<Flavor>DebugUnitTest --no-daemon
Rules:
MainDispatcherRule or Dispatchers.setMain()Default framework: XCTest
Test location: Inside the test target
MyApp/Feature/MyClass.swiftMyAppTests/Feature/MyClassTests.swiftNaming: test prefix + descriptive name
func testCalculateTotal_returnsZero_whenCartIsEmpty() { ... }
func testFormatPrice_throws_whenAmountIsNegative() { ... }
Run tests:
xcodebuild test -scheme <scheme> -destination 'platform=iOS Simulator,name=iPhone 15' -quiet
Default framework: flutter_test
Test location: test/ directory mirroring lib/
lib/feature/my_class.darttest/feature/my_class_test.dartNaming: test() with descriptive strings
test('calculateTotal returns zero when cart is empty', () { ... });
group('formatPrice', () {
test('throws when amount is negative', () { ... });
});
Run tests:
flutter test
Default framework: Jest
Test location: __tests__/ directory or co-located .test.ts files
Naming: describe + it blocks
describe('calculateTotal', () => {
it('returns zero when cart is empty', () => { ... });
});
Run tests:
npx jest
Test location: shared/src/commonTest/kotlin/ for shared code
Run tests:
./gradlew :shared:testDebugUnitTest # Android target
./gradlew :shared:iosSimulatorArm64Test # iOS target
Set testsWritten=false if:
Always explain why tests couldn't be written.