使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/phatnt95/salesforce-apex-agent --skill apex-testing開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
リポジトリの原文
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
Apex Testing
Testing strategy
Test behavior and business outcomes, not just coverage percentage.
Every non-trivial feature should consider:
- Happy path.
- Boundary/edge cases.
- Invalid input.
- Bulk input.
- No-data behavior.
- Permission/security behavior when applicable.
- Exception/error behavior.
- Async behavior when applicable.
- Callout success/failure when applicable.
Test data
- Prefer isolated test data created by the test or a reusable factory.
- Avoid depending on existing org data unless the platform requires it and the dependency is explicit.
- Make test records minimal but realistic.
- Do not hard-code production IDs.
Assertions
- Assert meaningful field values, record counts, status transitions, errors, and side effects.
- Avoid tests that only assert no exception was thrown.
- Use
Test.startTest()/Test.stopTest()to isolate governor limits and flush supported async work. - For bulk logic, test a meaningful multi-record collection rather than only a single record.
Callouts
Use HttpCalloutMock or the appropriate test abstraction. Assert both request/response behavior and resulting Salesforce state.
Async
For Queueable, Batchable, Scheduled, and future work, verify the observable outcome after Test.stopTest() and cover failure paths where practical.
Quality gate
Before declaring a test complete, ask:
- Would this fail if the business rule broke?
- Does it protect against regression?
- Does it exercise bulk behavior?
- Does it verify important negative/security cases?
- Is it independent of org-specific production data?
