slashdev 1.0.0 → 1.2.0

package/claude-skills/salesforce-development/references/testing-patterns.md

@@ -0,0 +1,438 @@
+# Testing Patterns — Reference
+
+Load this file when writing or reviewing Salesforce test classes.
+
+---
+
+## TestDataFactory
+
+A centralized factory class that creates fully-formed test records. Every test class uses this
+instead of building records inline — keeps tests DRY and ensures records pass validation rules.
+
+```apex
+@IsTest
+public class TestDataFactory {
+
+    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,
+                Industry = 'Technology',
+                BillingStreet = '123 Test St',
+                BillingCity = 'San Francisco',
+                BillingState = 'CA',
+                BillingPostalCode = '94105',
+                BillingCountry = 'US'
+            ));
+        }
+        if (doInsert) {
+            insert accounts;
+        }
+        return accounts;
+    }
+
+    public static List<Contact> createContacts(Integer count, Id accountId, Boolean doInsert) {
+        List<Contact> contacts = new List<Contact>();
+        for (Integer i = 0; i < count; i++) {
+            contacts.add(new Contact(
+                FirstName = 'Test',
+                LastName = 'Contact ' + i,
+                Email = 'test.contact' + i + '@example.com',
+                AccountId = accountId
+            ));
+        }
+        if (doInsert) {
+            insert contacts;
+        }
+        return contacts;
+    }
+
+    public static List<Opportunity> createOpportunities(Integer count, Id accountId, Boolean doInsert) {
+        List<Opportunity> opps = new List<Opportunity>();
+        for (Integer i = 0; i < count; i++) {
+            opps.add(new Opportunity(
+                Name = 'Test Opportunity ' + i,
+                AccountId = accountId,
+                StageName = 'Prospecting',
+                CloseDate = Date.today().addDays(30),
+                Amount = 10000
+            ));
+        }
+        if (doInsert) {
+            insert opps;
+        }
+        return opps;
+    }
+
+    public static User createTestUser(String profileName, Boolean doInsert) {
+        Profile p = [SELECT Id FROM Profile WHERE Name = :profileName LIMIT 1];
+        String uniqueStr = String.valueOf(DateTime.now().getTime());
+        User u = new User(
+            FirstName = 'Test',
+            LastName = 'User ' + uniqueStr,
+            Email = 'testuser' + uniqueStr + '@example.com',
+            Username = 'testuser' + uniqueStr + '@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;
+    }
+}
+```
+
+### Design principles
+
+- **`doInsert` parameter** — lets callers get records pre-insert for field modification,
+  or inserted for immediate use. Both paths are common.
+- **Populate required fields** — factory records must pass all validation rules and required
+  field constraints without the caller needing to know which fields are mandatory.
+- **Use unique values** — timestamps or counters in Name/Email to avoid duplicate rule
+  violations in bulk tests.
+
+---
+
+## Bulk Testing
+
+Every test should insert 200+ records to prove the code under test handles a full trigger
+batch. A test that works with 1 record and fails with 200 has a bulkification bug.
+
+```apex
+@IsTest
+private class AccountTriggerTest {
+
+    @IsTest
+    static void shouldHandleFullBatch() {
+        // 200 = one full trigger batch
+        List<Account> accounts = TestDataFactory.createAccounts(200, false);
+
+        Test.startTest();
+        insert accounts;
+        Test.stopTest();
+
+        // Assert on outcomes — query fresh to see trigger side-effects
+        List<Account> inserted = [
+            SELECT Id, Custom_Status__c
+            FROM Account
+            WHERE Id IN :accounts
+        ];
+        Assert.areEqual(200, inserted.size(), 'All 200 accounts should be inserted');
+        for (Account a : inserted) {
+            Assert.areEqual('New', a.Custom_Status__c,
+                'Trigger should set default status to New');
+        }
+    }
+}
+```
+
+### Why 200?
+
+- Triggers fire in batches of up to 200 records (Data Loader, Bulk API, batch Apex).
+- `Test.startTest()` resets governor limits, so the 200-record DML gets a fresh set of limits
+  — mimicking real-world trigger execution.
+
+---
+
+## Mocking HTTP Callouts
+
+Salesforce blocks real HTTP callouts in tests. Implement `HttpCalloutMock` and register it
+with `Test.setMock`.
+
+### Single-endpoint mock
+
+```apex
+@IsTest
+public class ExternalAccountServiceMock implements HttpCalloutMock {
+
+    private Integer statusCode;
+    private String body;
+
+    public ExternalAccountServiceMock(Integer statusCode, String body) {
+        this.statusCode = statusCode;
+        this.body = body;
+    }
+
+    public HttpResponse respond(HttpRequest req) {
+        HttpResponse res = new HttpResponse();
+        res.setStatusCode(this.statusCode);
+        res.setHeader('Content-Type', 'application/json');
+        res.setBody(this.body);
+        return res;
+    }
+}
+```
+
+### Using the mock in a test
+
+```apex
+@IsTest
+private class ExternalAccountServiceTest {
+
+    @IsTest
+    static void shouldDeserializeSuccessResponse() {
+        String mockBody = '{"id": "EXT-001", "name": "Acme Corp", "status": "active"}';
+        Test.setMock(HttpCalloutMock.class, new ExternalAccountServiceMock(200, mockBody));
+
+        Test.startTest();
+        ExternalAccountService.ExternalAccount result =
+            ExternalAccountService.getAccount('EXT-001');
+        Test.stopTest();
+
+        Assert.isNotNull(result, 'Result should not be null for 200 response');
+        Assert.areEqual('EXT-001', result.id, 'ID should match mock response');
+        Assert.areEqual('Acme Corp', result.name, 'Name should match mock response');
+    }
+
+    @IsTest
+    static void shouldReturnNullFor404() {
+        Test.setMock(HttpCalloutMock.class, new ExternalAccountServiceMock(404, ''));
+
+        Test.startTest();
+        ExternalAccountService.ExternalAccount result =
+            ExternalAccountService.getAccount('NONEXISTENT');
+        Test.stopTest();
+
+        Assert.isNull(result, 'Should return null for 404');
+    }
+
+    @IsTest
+    static void shouldThrowOnServerError() {
+        Test.setMock(HttpCalloutMock.class, new ExternalAccountServiceMock(500, 'Internal Server Error'));
+
+        Test.startTest();
+        try {
+            ExternalAccountService.getAccount('EXT-001');
+            Assert.fail('Should have thrown CalloutException');
+        } catch (CalloutException e) {
+            Assert.isTrue(e.getMessage().contains('500'), 'Exception should contain status code');
+        }
+        Test.stopTest();
+    }
+}
+```
+
+### Multi-endpoint mock
+
+For classes that call multiple endpoints, route by URL in `respond()`:
+
+```apex
+public HttpResponse respond(HttpRequest req) {
+    String endpoint = req.getEndpoint();
+    HttpResponse res = new HttpResponse();
+    res.setHeader('Content-Type', 'application/json');
+
+    if (endpoint.contains('/accounts')) {
+        res.setStatusCode(200);
+        res.setBody('{"id": "ACC-001"}');
+    } else if (endpoint.contains('/contacts')) {
+        res.setStatusCode(200);
+        res.setBody('{"id": "CON-001"}');
+    } else {
+        res.setStatusCode(404);
+        res.setBody('Not found');
+    }
+    return res;
+}
+```
+
+---
+
+## Async Testing — Test.startTest() / Test.stopTest()
+
+`Test.startTest()` and `Test.stopTest()` do two things:
+
+1. **Reset governor limits** — code between them gets a fresh set of limits, isolating the
+   code under test from test setup overhead.
+2. **Force async execution** — `@future`, `Queueable`, and `Batch Apex` jobs enqueued between
+   `startTest`/`stopTest` execute synchronously at `stopTest()`, making them testable.
+
+### Testing a Queueable
+
+```apex
+@IsTest
+private class SyncAccountToERPTest {
+
+    @IsTest
+    static void shouldCallERPEndpoint() {
+        Account a = TestDataFactory.createAccounts(1, true)[0];
+        Test.setMock(HttpCalloutMock.class, new ExternalAccountServiceMock(200, '{"status":"ok"}'));
+
+        Test.startTest();
+        System.enqueueJob(new SyncAccountToERP(new List<Id>{ a.Id }));
+        Test.stopTest();  // Queueable executes here synchronously
+
+        // Assert on side effects — e.g., a log record, field update, etc.
+    }
+}
+```
+
+### Testing Batch Apex
+
+```apex
+@IsTest
+private class DeactivateStaleLeadsBatchTest {
+
+    @IsTest
+    static void shouldDeactivateStaleLeads() {
+        List<Lead> leads = new List<Lead>();
+        for (Integer i = 0; i < 200; i++) {
+            leads.add(new Lead(
+                FirstName = 'Test', LastName = 'Lead ' + i, Company = 'TestCo',
+                Status = 'Open'
+            ));
+        }
+        insert leads;
+        // Backdate LastActivityDate via Test.setCreatedDate or a field update
+        // (LastActivityDate is read-only — use a proxy field or adjust the query for testing)
+
+        Test.startTest();
+        Database.executeBatch(new DeactivateStaleLeadsBatch(), 200);
+        Test.stopTest();  // All batch execute() calls run here
+
+        List<Lead> updated = [SELECT Status FROM Lead WHERE Id IN :leads];
+        for (Lead l : updated) {
+            Assert.areEqual('Closed - Not Converted', l.Status, 'Stale leads should be deactivated');
+        }
+    }
+}
+```
+
+---
+
+## System.runAs — Testing Sharing and FLS
+
+`System.runAs` executes code in the context of a specific user, enforcing their profile
+permissions, sharing rules, and field-level security. Use it to verify that `with sharing`
+classes and FLS checks work correctly.
+
+```apex
+@IsTest
+private class AccountServiceTest {
+
+    @IsTest
+    static void shouldEnforceSharingRules() {
+        // Create a restricted user
+        User restrictedUser = TestDataFactory.createTestUser('Standard User', true);
+
+        // Create an account owned by the running user (not the restricted user)
+        Account privateAccount = TestDataFactory.createAccounts(1, true)[0];
+
+        System.runAs(restrictedUser) {
+            Test.startTest();
+            List<Account> visible = new AccountService().getVisibleAccounts();
+            Test.stopTest();
+
+            // Restricted user should NOT see the private account
+            // (assuming OWD for Account is Private)
+            Set<Id> visibleIds = new Set<Id>();
+            for (Account a : visible) {
+                visibleIds.add(a.Id);
+            }
+            Assert.isFalse(visibleIds.contains(privateAccount.Id),
+                'Restricted user should not see accounts they do not own');
+        }
+    }
+}
+```
+
+### Caveats
+
+- `System.runAs` does NOT count against governor limits for the enclosing test.
+- Mixed DML restrictions apply — inserting a User and a standard object in the same
+  transaction throws an error. Insert the user first, then use `System.runAs` for the rest.
+- `System.runAs` only works in `@IsTest` methods.
+
+---
+
+## @testSetup — Shared Test Data
+
+`@testSetup` runs once per test class and creates records available to all `@IsTest` methods
+in that class. Each test method gets its own copy (rolled back after each method), so tests
+remain independent.
+
+```apex
+@IsTest
+private class OpportunityServiceTest {
+
+    @testSetup
+    static void setupData() {
+        List<Account> accounts = TestDataFactory.createAccounts(5, true);
+        for (Account a : accounts) {
+            TestDataFactory.createOpportunities(10, a.Id, true);
+        }
+    }
+
+    @IsTest
+    static void shouldCalculateTotalPipeline() {
+        Test.startTest();
+        Decimal total = OpportunityService.getTotalPipeline();
+        Test.stopTest();
+
+        Assert.areEqual(500000, total, '5 accounts x 10 opps x $10,000 = $500,000');
+    }
+
+    @IsTest
+    static void shouldFilterByStage() {
+        // This test gets the SAME data as above — fresh copy, not affected by other tests
+        List<Opportunity> opps = [SELECT Id FROM Opportunity WHERE StageName = 'Prospecting'];
+        Assert.areEqual(50, opps.size(), 'All 50 opps should be in Prospecting stage');
+    }
+}
+```
+
+### Caveats
+
+- `@testSetup` cannot be used with `@IsTest(SeeAllData=true)` — they are mutually exclusive.
+- Records created in `@testSetup` are not visible to the `@testSetup` method's own
+  `System.runAs` blocks — each `@IsTest` method sees a fresh snapshot.
+- If any `@IsTest` method needs different data, create it within that method — don't
+  over-centralize.
+
+---
+
+## Assert Patterns
+
+### Modern Assert class (Spring '22+)
+
+Prefer `Assert` over the legacy `System.assert*` methods. The modern class has clearer
+method names and better error messages.
+
+```apex
+// Equality
+Assert.areEqual(expected, actual, 'Descriptive message explaining what went wrong');
+Assert.areNotEqual(unexpected, actual, 'Values should differ because...');
+
+// Null checks
+Assert.isNull(value, 'Should be null because...');
+Assert.isNotNull(value, 'Should not be null because...');
+
+// Boolean
+Assert.isTrue(condition, 'Condition should be true because...');
+Assert.isFalse(condition, 'Condition should be false because...');
+
+// Forced failure (in catch blocks for expected exceptions)
+Assert.fail('Should have thrown an exception');
+
+// Instance check
+Assert.isInstanceOfType(obj, Account.class, 'Should be an Account');
+```
+
+### Rules
+
+- **Always include a message parameter.** When a test fails in a CI pipeline, the message
+  is the only context the developer has. "Expected 200 but got 0" is useless without
+  "All accounts should have been inserted by the bulk trigger."
+- **Assert on specific values, not just non-null.** `Assert.isNotNull(result)` proves the
+  query returned something — it doesn't prove it returned the *right* thing.
+- **One logical assertion per test method** when practical. Multiple assertions are fine if
+  they verify the same operation's outcome (e.g., checking multiple fields on a record), but
+  avoid combining unrelated assertions that make failures ambiguous.
+- **Never use `System.assertEquals` in new code** — it still works but `Assert.areEqual` is
+  the modern replacement with consistent naming.

package/claude-skills/secure-deploy/SKILL.md

@@ -0,0 +1,219 @@
+---
+name: secure-deploy
+description: Retrofit a project's CI/CD pipelines, Dockerfiles, and deploy scripts to use Socket Firewall (sfw) for all dependency installs. Use when the user asks to "secure deploy", "set up sfw in CI", "add socket firewall to production", or whenever you're editing a CI workflow / Dockerfile / deploy script that installs dependencies.
+version: "1.0"
+owner: michael@slashdev.io
+---
+
+# Secure Deploy — Retrofit projects to use Socket Firewall in production
+
+Slashdev requires every dependency install — local AND production — to be wrapped
+with Socket Firewall (`sfw`). This protects against supply-chain attacks
+(compromised packages, typosquats, dependency confusion) by scanning every package
+against Socket's vulnerability/malware database before it's allowed to install.
+
+When a developer asks you to set up production deployment, edit a CI pipeline, write
+a Dockerfile, or deploy a project, **you must ensure every install command uses `sfw`**.
+
+This skill walks you through the retrofit systematically.
+
+## When to use this skill
+
+Trigger automatically (without being asked) whenever you're about to:
+- Create or edit a `.github/workflows/*.yml` file with an `npm`/`pnpm`/`yarn`/`bun`/`composer`/`pip` install step
+- Create or edit a `Dockerfile` that runs an install command
+- Create or edit `.gitlab-ci.yml`, `bitbucket-pipelines.yml`, `circleci/config.yml`, or any other CI config
+- Create or edit a `deploy.sh`, `Procfile`, or `Makefile` install target
+- Modify the `scripts` section of `package.json` to add an install-related step
+
+Trigger explicitly when the user says: "secure deploy", "add sfw to CI", "set up socket firewall in production", "retrofit production for socket firewall", "audit deploy for sfw".
+
+## Step-by-step retrofit playbook
+
+### Step 1 — Discover deployment surface
+
+Use Glob to find every file that could install dependencies in CI or production:
+
+```
+.github/workflows/*.yml
+.github/workflows/*.yaml
+.gitlab-ci.yml
+.gitlab/*.yml
+bitbucket-pipelines.yml
+.circleci/config.yml
+azure-pipelines.yml
+Jenkinsfile
+Dockerfile
+Dockerfile.*
+*.dockerfile
+docker-compose*.yml
+Procfile
+deploy.sh
+deploy/*.sh
+scripts/deploy*.sh
+Makefile
+package.json
+```
+
+For each file found, Read it and look for any of these patterns:
+
+- `npm install`, `npm i`, `npm ci`, `npm add`
+- `pnpm install`, `pnpm i`, `pnpm add`
+- `yarn`, `yarn install`, `yarn add`
+- `bun install`, `bun i`, `bun add`
+- `composer install`, `composer require`, `composer update`
+- `pip install`, `pip3 install`, `uv install`, `uv sync`, `uv add`
+
+Note any line that already starts with `sfw ` — those are already secured and don't
+need to be touched.
+
+### Step 2 — Plan the changes
+
+For each install command found, plan one of these rewrites:
+
+**a) GitHub Actions workflow YAML**
+
+Before:
+```yaml
+- name: Install dependencies
+  run: npm ci
+```
+
+After:
+```yaml
+- name: Install Socket Firewall
+  run: npm install -g @socketsecurity/cli
+- name: Install dependencies
+  run: sfw npm ci
+```
+
+If a job has multiple install steps, only one `Install Socket Firewall` step is needed
+per job (it persists across steps because they share the same runner).
+
+**b) Dockerfile**
+
+Before:
+```dockerfile
+RUN npm ci
+```
+
+After:
+```dockerfile
+RUN npm install -g @socketsecurity/cli && sfw npm ci
+```
+
+For Composer:
+```dockerfile
+RUN npm install -g @socketsecurity/cli && sfw composer install --no-dev --optimize-autoloader
+```
+
+(npm is the simplest install vector for sfw itself; if the base image doesn't have
+Node, install Node first or use the official Socket installer.)
+
+**c) Shell deploy scripts (`deploy.sh`, etc.)**
+
+Before:
+```bash
+npm ci --omit=dev
+```
+
+After:
+```bash
+# Ensure sfw is available
+if ! command -v sfw >/dev/null 2>&1; then
+  npm install -g @socketsecurity/cli
+fi
+sfw npm ci --omit=dev
+```
+
+**d) `package.json` scripts**
+
+Before:
+```json
+{
+  "scripts": {
+    "postinstall": "npm install --prefix ./client"
+  }
+}
+```
+
+After:
+```json
+{
+  "scripts": {
+    "postinstall": "sfw npm install --prefix ./client"
+  }
+}
+```
+
+(Don't add the `npm install -g @socketsecurity/cli` step inside `package.json` — assume
+sfw is already installed wherever this script runs. If it's running in CI, the workflow
+or Dockerfile should have installed sfw at the top.)
+
+### Step 3 — Show the diff and confirm
+
+Before writing any changes, show the user a clear summary:
+
+> Found N install commands across M files. Proposed changes:
+>
+> 1. `.github/workflows/ci.yml` — wrap `npm ci` in build job (+ add sfw install step)
+> 2. `Dockerfile` — wrap `RUN npm ci` with sfw install
+> 3. `package.json` — wrap postinstall script
+>
+> Apply these changes?
+
+Use AskUserQuestion if there's any ambiguity (e.g. multiple jobs in a workflow, unclear
+whether a step is part of the build or local-only). For Dockerfiles especially, ask
+about the base image — if it doesn't have Node, the sfw install command needs to be
+different.
+
+### Step 4 — Apply the changes
+
+Use Edit to apply each change. After applying:
+
+1. **Validate YAML/JSON syntax** — for any modified `.yml` or `.json` file, run a quick
+   parse check (e.g. `python3 -c 'import yaml,sys; yaml.safe_load(open("path"))'` for
+   YAML, or `python3 -m json.tool path` for JSON). Fix any syntax errors.
+2. **Run a build smoke test if possible** — for Dockerfiles, suggest the user run
+   `docker build .` locally. For GitHub Actions, suggest pushing to a feature branch
+   and watching the workflow run.
+3. **Document what was changed** — print a final summary listing every file modified
+   and what was added.
+
+### Step 5 — Verify CI doesn't already use a different security tool
+
+If during Step 1 you find references to other security scanners (Snyk, Dependabot,
+Trivy, npm audit, etc.), don't remove them — they complement Socket Firewall, they
+don't replace it. Mention to the user: "I found existing security scanning via X. I
+left it in place — Socket Firewall complements it by blocking malicious packages
+*before* they install, while X scans the installed tree."
+
+## Important conventions
+
+- **Never silently change install commands.** Always show the diff and get
+  confirmation before writing CI/deploy files. These are production-critical files.
+- **Don't add sfw to dev-only `node_modules` install steps in `package.json`** unless
+  the user explicitly asks. The PreToolUse hook handles dev-side enforcement
+  automatically; only retrofit `package.json` scripts that run in CI/deploy contexts.
+- **Don't try to install Socket Firewall globally on the user's machine** as part of
+  this skill. That's the developer's responsibility, and the slashdev hook will warn
+  them if it's missing. This skill only modifies project files.
+- **Don't touch `.lock` files** (`package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`,
+  `composer.lock`, `bun.lockb`). They're generated.
+- **Preserve existing flags** — when wrapping `npm ci --omit=dev` with `sfw`, keep
+  the `--omit=dev` flag.
+
+## Output format
+
+Always end the skill with:
+
+```
+✓ Secured N install commands across M files:
+  - <file>: <change summary>
+  - <file>: <change summary>
+
+Next steps:
+  - Test locally (if applicable)
+  - Push to a feature branch and watch CI
+  - Confirm sfw is available in your CI environment (the install step is now in place)
+```