@salesforce/afv-skills 1.1.0 → 1.2.0

package/skills/apex-test-class/references/mocking-patterns.md

@@ -1,219 +0,0 @@
-# Mocking Patterns
-
-## HTTP Callout Mocking
-
-Apex doesn't allow real HTTP callouts in tests. Use `HttpCalloutMock` interface.
-
-### Basic Mock Implementation
-
-```apex
-@IsTest
-public class MockHttpResponse implements HttpCalloutMock {
-    
-    private Integer statusCode;
-    private String body;
-    
-    public MockHttpResponse(Integer statusCode, String body) {
-        this.statusCode = statusCode;
-        this.body = body;
-    }
-    
-    public HTTPResponse respond(HTTPRequest req) {
-        HttpResponse res = new HttpResponse();
-        res.setStatusCode(statusCode);
-        res.setBody(body);
-        res.setHeader('Content-Type', 'application/json');
-        return res;
-    }
-}
-```
-
-### Using the Mock
-
-```apex
-@IsTest
-private static void shouldProcessApiResponse_WhenCalloutSucceeds() {
-    // Given
-    String mockResponse = '{"status": "success", "data": [{"id": "123"}]}';
-    Test.setMock(HttpCalloutMock.class, new MockHttpResponse(200, mockResponse));
-    
-    // When
-    Test.startTest();
-    List<ExternalRecord> results = MyIntegrationService.fetchRecords();
-    Test.stopTest();
-    
-    // Then
-    System.Assert.areEqual(1, results.size(), 'Should parse one record from response');
-    System.Assert.areEqual('123', results[0].externalId, 'Should extract correct ID');
-}
-
-@IsTest
-private static void shouldHandleError_WhenCalloutFails() {
-    // Given
-    String errorResponse = '{"error": "Unauthorized"}';
-    Test.setMock(HttpCalloutMock.class, new MockHttpResponse(401, errorResponse));
-    
-    // When
-    Test.startTest();
-    CalloutResult result = MyIntegrationService.fetchRecords();
-    Test.stopTest();
-    
-    // Then
-    System.Assert.areEqual(false, result.isSuccess, 'Should indicate failure');
-    System.Assert.isTrue(result.errorMessage.contains('Unauthorized'), 'Should capture error');
-}
-```
-
-### Multi-Request Mock
-
-For services making multiple callouts:
-
-```apex
-@IsTest
-public class MultiRequestMock implements HttpCalloutMock {
-    
-    private Map<String, HttpResponse> endpointResponses;
-    
-    public MultiRequestMock(Map<String, HttpResponse> responses) {
-        this.endpointResponses = responses;
-    }
-    
-    public HTTPResponse respond(HTTPRequest req) {
-        String endpoint = req.getEndpoint();
-        
-        for (String key : endpointResponses.keySet()) {
-            if (endpoint.contains(key)) {
-                return endpointResponses.get(key);
-            }
-        }
-        
-        // Default 404 if no match
-        HttpResponse res = new HttpResponse();
-        res.setStatusCode(404);
-        res.setBody('{"error": "Not found"}');
-        return res;
-    }
-}
-
-// Usage:
-Map<String, HttpResponse> mocks = new Map<String, HttpResponse>();
-
-HttpResponse authResponse = new HttpResponse();
-authResponse.setStatusCode(200);
-authResponse.setBody('{"token": "abc123"}');
-mocks.put('/oauth/token', authResponse);
-
-HttpResponse dataResponse = new HttpResponse();
-dataResponse.setStatusCode(200);
-dataResponse.setBody('{"records": []}');
-mocks.put('/api/records', dataResponse);
-
-Test.setMock(HttpCalloutMock.class, new MultiRequestMock(mocks));
-```
-
-## StaticResourceCalloutMock
-
-For complex response bodies, store JSON in Static Resources:
-
-```apex
-@IsTest
-private static void shouldParseComplexResponse() {
-    StaticResourceCalloutMock mock = new StaticResourceCalloutMock();
-    mock.setStaticResource('TestApiResponse'); // Static Resource name
-    mock.setStatusCode(200);
-    mock.setHeader('Content-Type', 'application/json');
-    
-    Test.setMock(HttpCalloutMock.class, mock);
-    
-    Test.startTest();
-    Result r = MyService.callExternalApi();
-    Test.stopTest();
-    
-    System.Assert.isNotNull(r, 'Should parse response');
-}
-```
-
-## Stub API (Enterprise Pattern)
-
-For mocking Apex class dependencies using `System.StubProvider`:
-
-```apex
-@IsTest
-public class MyServiceMock implements System.StubProvider {
-    
-    public Object handleMethodCall(
-        Object stubbedObject,
-        String stubbedMethodName,
-        Type returnType,
-        List<Type> paramTypes,
-        List<String> paramNames,
-        List<Object> args
-    ) {
-        if (stubbedMethodName == 'getAccountData') {
-            return new AccountData('Mock Account', 'Active');
-        }
-        return null;
-    }
-}
-
-// Usage in test:
-@IsTest
-private static void shouldUseAccountData() {
-    MyServiceMock mockProvider = new MyServiceMock();
-    IMyService mockService = (IMyService)Test.createStub(IMyService.class, mockProvider);
-    
-    // Inject mock into class under test
-    MyController controller = new MyController(mockService);
-    
-    Test.startTest();
-    String result = controller.displayAccountInfo();
-    Test.stopTest();
-    
-    System.Assert.isTrue(result.contains('Mock Account'), 'Should use mocked data');
-}
-```
-
-## Email Mocking
-
-Apex sends real emails by default. Use limits to verify:
-
-```apex
-@IsTest
-private static void shouldSendEmail_WhenTriggered() {
-    Integer emailsBefore = Limits.getEmailInvocations();
-    
-    Test.startTest();
-    MyService.sendNotification(testContact);
-    Test.stopTest();
-    
-    // Verify email was queued (not actually sent in tests)
-    System.Assert.areEqual(
-        emailsBefore + 1, 
-        Limits.getEmailInvocations(), 
-        'One email should be sent'
-    );
-}
-```
-
-## Platform Event Testing
-
-```apex
-@IsTest
-private static void shouldPublishEvent_WhenRecordCreated() {
-    Test.startTest();
-    
-    // Enable event delivery in test context
-    Test.enableChangeDataCapture();
-    
-    Account acc = TestDataFactory.createAccount(true);
-    
-    // Deliver events
-    Test.getEventBus().deliver();
-    
-    Test.stopTest();
-    
-    // Query platform event trigger results
-    List<EventLog__c> logs = [SELECT Id FROM EventLog__c WHERE AccountId__c = :acc.Id];
-    System.Assert.areEqual(1, logs.size(), 'Event handler should create log record');
-}
-```

package/skills/apex-test-class/references/test-data-factory.md

@@ -1,176 +0,0 @@
-# TestDataFactory Patterns
-
-## Overview
-
-TestDataFactory is a centralized utility class for creating test records with sensible defaults. It ensures consistent test data across all test classes and reduces duplication.
-
-## Base Template
-
-```apex
-@IsTest
-public class TestDataFactory {
-    
-    // ============ ACCOUNTS ============
-    
-    public static List<Account> createAccounts(Integer count, Boolean doInsert) {
-        List<Account> accounts = new List<Account>();
-        for (Integer i = 0; i < count; i++) {
-            accounts.add(new Account(
-                Name = 'Test Account ' + i,
-                BillingStreet = '123 Test St',
-                BillingCity = 'San Francisco',
-                BillingState = 'CA',
-                BillingPostalCode = '94105',
-                BillingCountry = 'USA',
-                Industry = 'Technology',
-                Type = 'Customer'
-            ));
-        }
-        if (doInsert) insert accounts;
-        return accounts;
-    }
-    
-    public static Account createAccount(Boolean doInsert) {
-        return createAccounts(1, doInsert)[0];
-    }
-    
-    // ============ CONTACTS ============
-    
-    public static List<Contact> createContacts(List<Account> accounts, Integer countPerAccount, Boolean doInsert) {
-        List<Contact> contacts = new List<Contact>();
-        Integer index = 0;
-        for (Account acc : accounts) {
-            for (Integer i = 0; i < countPerAccount; i++) {
-                contacts.add(new Contact(
-                    FirstName = 'Test',
-                    LastName = 'Contact ' + index,
-                    Email = 'test.contact' + index + '@example.com',
-                    Phone = '555-000-' + String.valueOf(index).leftPad(4, '0'),
-                    AccountId = acc.Id
-                ));
-                index++;
-            }
-        }
-        if (doInsert) insert contacts;
-        return contacts;
-    }
-    
-    // ============ OPPORTUNITIES ============
-    
-    public static List<Opportunity> createOpportunities(List<Account> accounts, Integer countPerAccount, Boolean doInsert) {
-        List<Opportunity> opps = new List<Opportunity>();
-        Integer index = 0;
-        for (Account acc : accounts) {
-            for (Integer i = 0; i < countPerAccount; i++) {
-                opps.add(new Opportunity(
-                    Name = 'Test Opportunity ' + index,
-                    AccountId = acc.Id,
-                    StageName = 'Prospecting',
-                    CloseDate = Date.today().addDays(30),
-                    Amount = 10000 + (index * 1000)
-                ));
-                index++;
-            }
-        }
-        if (doInsert) insert opps;
-        return opps;
-    }
-    
-    // ============ USERS ============
-    
-    public static User createUser(String profileName, Boolean doInsert) {
-        Profile p = [SELECT Id FROM Profile WHERE Name = :profileName LIMIT 1];
-        String uniqueKey = String.valueOf(DateTime.now().getTime());
-        
-        User u = new User(
-            FirstName = 'Test',
-            LastName = 'User ' + uniqueKey,
-            Email = 'testuser' + uniqueKey + '@example.com',
-            Username = 'testuser' + uniqueKey + '@example.com.test',
-            Alias = 'tuser',
-            TimeZoneSidKey = 'America/Los_Angeles',
-            LocaleSidKey = 'en_US',
-            EmailEncodingKey = 'UTF-8',
-            LanguageLocaleKey = 'en_US',
-            ProfileId = p.Id
-        );
-        if (doInsert) insert u;
-        return u;
-    }
-    
-    // ============ CUSTOM OBJECTS ============
-    
-    // Add methods for your custom objects following the same pattern:
-    // public static List<MyObject__c> createMyObjects(Integer count, Boolean doInsert) { ... }
-}
-```
-
-## Field Override Pattern
-
-Allow callers to override default values:
-
-```apex
-public static Account createAccount(Map<String, Object> fieldOverrides, Boolean doInsert) {
-    Account acc = new Account(
-        Name = 'Test Account',
-        Industry = 'Technology'
-    );
-    
-    // Apply overrides
-    for (String fieldName : fieldOverrides.keySet()) {
-        acc.put(fieldName, fieldOverrides.get(fieldName));
-    }
-    
-    if (doInsert) insert acc;
-    return acc;
-}
-
-// Usage:
-Account acc = TestDataFactory.createAccount(new Map<String, Object>{
-    'Name' => 'Custom Name',
-    'Industry' => 'Healthcare'
-}, true);
-```
-
-## Handling Required Fields and Validation Rules
-
-```apex
-public static Account createAccountWithRequiredFields(Boolean doInsert) {
-    Account acc = new Account(
-        Name = 'Test Account',
-        // Required custom fields
-        External_Id__c = 'EXT-' + String.valueOf(DateTime.now().getTime()),
-        // Fields required by validation rules
-        Phone = '555-123-4567',
-        Website = 'https://example.com'
-    );
-    if (doInsert) insert acc;
-    return acc;
-}
-```
-
-## Record Type Support
-
-```apex
-public static Account createAccountByRecordType(String recordTypeName, Boolean doInsert) {
-    Id recordTypeId = Schema.SObjectType.Account
-        .getRecordTypeInfosByDeveloperName()
-        .get(recordTypeName)
-        .getRecordTypeId();
-    
-    Account acc = new Account(
-        Name = 'Test Account',
-        RecordTypeId = recordTypeId
-    );
-    if (doInsert) insert acc;
-    return acc;
-}
-```
-
-## Best Practices
-
-1. **Always include doInsert parameter** - Allows flexibility for tests that need to modify records before insert
-2. **Use unique identifiers** - Include index or timestamp in Name/Email fields to avoid duplicates
-3. **Set all required fields** - Include all fields required by validation rules
-4. **Return the created records** - Enables chaining and further manipulation
-5. **Create bulk methods first** - Single record methods should call bulk methods with count=1

package/skills/deployment-readiness-check/SKILL.md

@@ -1,257 +0,0 @@
----
-name: deployment-readiness-check
-description: Comprehensive pre-deployment validation checklist for Salesforce releases. Use before deploying to production to catch metadata issues, test coverage gaps, and configuration errors.
-license: Apache-2.0
-compatibility: Requires Salesforce CLI, jq, bash
-metadata:
-  author: afv-library
-  version: "1.0"
-allowed-tools: Bash Read
----
-
-## When to Use This Skill
-
-Use this skill before deploying Salesforce metadata to production (or higher environments) to:
-- Validate metadata quality and completeness
-- Check test coverage meets organizational standards
-- Verify security settings and permissions
-- Identify configuration issues before deployment
-- Generate deployment documentation
-
-## Prerequisites
-
-- Salesforce CLI installed and authenticated to target org
-- `jq` command-line JSON processor installed
-- Bash shell (Linux, macOS, or WSL on Windows)
-- Source metadata in SFDX project format
-
-## Step 1: Run Metadata Validation
-
-Execute the validation script to check for common metadata issues:
-
-```bash
-bash scripts/check_metadata.sh
-```
-
-The script validates:
-- **Metadata format** - Ensures all XML is well-formed
-- **API versions** - Checks for outdated API versions
-- **Deprecated features** - Identifies deprecated components
-- **Naming conventions** - Validates standard naming patterns
-- **File completeness** - Ensures meta.xml files are present
-
-Review the output for any warnings or errors before proceeding.
-
-## Step 2: Verify Test Coverage
-
-Check that your Apex test coverage meets organizational standards:
-
-```bash
-# Run all tests and generate coverage report
-sf apex test run --test-level RunLocalTests --result-format human --code-coverage --wait 10
-
-# Check coverage percentage
-sf apex get test --test-run-id <test-run-id> --code-coverage --result-format json | jq '.summary.testRunCoverage'
-```
-
-**Minimum requirements**:
-- Overall org coverage: ≥75% (Salesforce minimum)
-- Individual class coverage: ≥75% (recommended)
-- No classes with 0% coverage
-
-If coverage is below threshold:
-1. Identify uncovered classes using the coverage report
-2. Add test methods to increase coverage
-3. Rerun tests until requirements are met
-
-## Step 3: Security and Permissions Review
-
-Review security settings and permissions to ensure proper access controls:
-
-1. **Profile and Permission Set Review**
-   - Check that custom profiles/permission sets follow least-privilege principle
-   - Verify admin permissions are not granted to standard users
-   - Ensure sensitive objects have appropriate FLS
-
-2. **Sharing Rules and OWD**
-   - Review Organization-Wide Defaults are appropriate
-   - Validate sharing rules grant necessary access without over-sharing
-   - Check for public groups with excessive membership
-
-3. **API Access**
-   - Verify Connected Apps have appropriate scopes
-   - Check Named Credentials use secure authentication
-   - Review Remote Site Settings are necessary
-
-Consult the [security checklist reference](references/security_checklist.md) for detailed guidance.
-
-## Step 4: Configuration Validation
-
-Verify configuration settings are deployment-ready:
-
-```bash
-# Check for hardcoded URLs or IDs
-grep -r "https://.*\.salesforce\.com" force-app/main/default/
-grep -r "[a-zA-Z0-9]{15,18}" force-app/main/default/ | grep -v "meta.xml"
-
-# Validate Custom Settings and Custom Metadata
-sf project retrieve start --metadata CustomObject:*__c
-```
-
-**Configuration checklist**:
-- [ ] No hardcoded production URLs in code
-- [ ] No hardcoded record IDs
-- [ ] Custom Settings configured correctly for target org
-- [ ] Custom Metadata Types populated appropriately
-- [ ] Email templates reference correct org email
-- [ ] Reports and Dashboards folders have correct permissions
-
-## Step 5: Review Dependencies
-
-Check for dependency conflicts or missing components:
-
-```bash
-# Generate dependency report
-sf project deploy validate --manifest package.xml --test-level RunLocalTests --verbose
-
-# Check for missing dependencies
-grep -i "error.*component" deployment_log.txt
-```
-
-Common dependency issues:
-- Missing Custom Fields referenced in code
-- Validation Rules referencing deleted fields
-- Workflows or Process Builders using deprecated actions
-- Lightning Components with missing design resources
-
-See [dependency troubleshooting guide](references/dependency_resolution.md) for solutions.
-
-## Step 6: Generate Deployment Checklist
-
-Use the deployment checklist template to document your release:
-
-```bash
-cp assets/deployment_checklist.md deployment_checklist_$(date +%Y%m%d).md
-```
-
-Fill out the checklist with:
-- [ ] Deployment date and time window
-- [ ] Components being deployed (attach package.xml)
-- [ ] Test execution results and coverage
-- [ ] Backup verification (data and metadata)
-- [ ] Rollback procedure documented
-- [ ] Stakeholders notified
-- [ ] Post-deployment validation steps
-- [ ] Monitoring plan for 24-48 hours
-
-## Step 7: Execute Pre-Deployment Validation
-
-Run a validation-only deployment to catch issues before actual deployment:
-
-```bash
-# Validate deployment without committing
-sf project deploy validate \
-  --manifest package.xml \
-  --test-level RunLocalTests \
-  --verbose
-
-# Save the validation ID for quick deploy
-sf project deploy start --use-most-recent-validation --async
-```
-
-**Benefits of validation**:
-- Tests run in production environment
-- Identifies environment-specific issues
-- Generates Quick Deploy ID for faster deployment
-- No changes committed until you confirm
-
-Review validation results and address any failures before scheduling deployment.
-
-## Step 8: Prepare Rollback Plan
-
-Document rollback procedures before deploying:
-
-1. **Backup current state**
-   ```bash
-   sf project retrieve start --manifest package.xml --target-org production
-   git tag pre-deployment-$(date +%Y%m%d) && git push --tags
-   ```
-
-2. **Test rollback procedure** in sandbox:
-   - Deploy previous version of metadata
-   - Verify functionality is restored
-   - Document any data cleanup required
-
-3. **Establish rollback criteria**:
-   - Critical bugs found within 2 hours
-   - Core functionality broken
-   - Performance degradation >50%
-   - Data integrity issues
-
-See [rollback procedures reference](references/rollback_procedures.md) for detailed steps.
-
-## Post-Deployment Validation
-
-After successful deployment, verify the release:
-
-1. **Smoke tests** - Execute critical user workflows
-2. **Monitor logs** - Check debug logs for errors (24-48 hours)
-3. **Query test data** - Verify triggers and automation work correctly
-4. **User acceptance** - Confirm with stakeholders functionality works
-5. **Performance check** - Review governor limit usage in logs
-
-## Common Issues and Solutions
-
-### Issue: Test Coverage Drops Below 75%
-
-**Cause**: New Apex classes added without sufficient tests.
-
-**Solution**:
-1. Run `sf apex test run --code-coverage` to identify gaps
-2. Add test methods covering uncovered lines
-3. Revalidate coverage
-
-### Issue: Validation Fails with "Component Not Found"
-
-**Cause**: Missing dependency in package.xml.
-
-**Solution**:
-1. Review error message for missing component
-2. Add component to package.xml
-3. Retrieve component from source org if needed
-4. Revalidate
-
-### Issue: Permission Errors After Deployment
-
-**Cause**: FLS or object permissions not deployed correctly.
-
-**Solution**:
-1. Verify profiles/permission sets are in package.xml
-2. Check that CustomObject metadata includes field permissions
-3. Deploy profiles separately if needed
-4. Use Permission Set Groups for complex permission hierarchies
-
-## Best Practices
-
-1. **Always validate before deploying** - Never deploy directly to production without validation
-2. **Run full test suite** - Use RunLocalTests, not NoTestRun
-3. **Deploy during maintenance windows** - Minimize impact on users
-4. **Communicate with stakeholders** - Notify before, during, and after deployment
-5. **Monitor post-deployment** - Watch logs and user feedback for 24-48 hours
-6. **Document everything** - Maintain deployment logs and decisions
-7. **Use version control tags** - Tag releases for easy rollback
-
-## References
-
-- [Security Checklist](references/security_checklist.md) - Detailed security review steps
-- [Dependency Resolution Guide](references/dependency_resolution.md) - Solve dependency conflicts
-- [Rollback Procedures](references/rollback_procedures.md) - Step-by-step rollback guide
-- [Deployment Checklist Template](assets/deployment_checklist.md) - Reusable checklist
-
-## Automation Opportunities
-
-Consider automating this skill:
-- **CI/CD Integration** - Run validation script in pipeline
-- **Scheduled Coverage Checks** - Monitor test coverage daily
-- **Auto-generated Documentation** - Create deployment notes from package.xml
-- **Slack/Email Notifications** - Alert team of deployment status