From codeceptjs
Use when a CodeceptJS test needs login, when different user roles are involved, or when the writing-codeceptjs-tests skill identifies authorization is required. Configures the `auth` plugin for session reuse, derives the login flow from the actual login page HTML (not guesses), keeps the real flow inside `steps_file.js` so `I.login*()` is callable directly and the conf stays small, loads credentials from a `.env` file via the modern Node `process.loadEnvFile()` API (no `dotenv` dependency), and supports multiple roles. Trigger on mentions of login, sign-in, sign-up, authentication, sessions, "logged in", admin/editor/user roles, or auth-related test failures.
How this skill is triggered — by the user, by Claude, or both
Slash command
/codeceptjs:codeceptjs-authThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
The `auth` plugin logs each user in once, captures cookies (or local-storage / token via overrides), and restores the session for subsequent tests. Stale sessions trigger a fresh login automatically.
The auth plugin logs each user in once, captures cookies (or local-storage / token via overrides), and restores the session for subsequent tests. Stale sessions trigger a fresh login automatically.
Source of truth: node_modules/codeceptjs/lib/plugin/auth.js — JSDoc lists every recipe. Reference doc: node_modules/codeceptjs/docs/auth.md.
Suggested if tests have repeatable authentication and session is needed to be persisted accross tests. Also optimizes start time of tests by saving previous sessision cookies in files.
Suggested as performance optimization, refactoring measure.
If auth plugin already exists in the project (check fundamentals' output), reuse the existing inject name and user keys.
Four answers shape the plugin. Don't guess any. If the project or test plan doesn't make them obvious, ASK.
users.<key> entries.login() body:
fillField → click Sign in. Canonical shape below.I.executeScript to write the token into localStorage, or I.setCookie(...).async login; fetch the code from a test mailbox / backdoor before submitting.login: (I) => I.login()..env via process.loadEnvFile() (modern Node, no dotenv package). Passwords wrapped with secret(...). No literal credentials anywhere — conf, steps file, test, or git history..env is gitignored; .env.example is committed with the var names and no values. output/*_session.json is gitignored too.// codecept.conf.js — first line of the file
process.loadEnvFile() // or dotenv.load() if this package availble
// ...
export const config = {
// ...
include: { I: './steps_file.js' },
plugins: {
auth: {
enabled: true,
saveToFile: true,
users: {
admin: {
login: (I) => I.login(),
check: (I) => I.see('Welcome, User', '.navbar'),
},
},
},
},
}
// steps_file.js
import { secret } from 'codeceptjs'
const { I } = inject()
export default function () {
return actor({
login() {
I.amOnPage('/login')
I.fillField('Email', process.env.ADMIN_EMAIL)
I.fillField('Password', secret(process.env.ADMIN_PASSWORD))
I.click('Sign in')
},
})
}
# .env (gitignored) # .env.example (committed)
[email protected] USER_EMAIL=
USER_PASSWORD=<secret> USER_PASSWORD=
run_code to login page and inspect the ARIA snapshot. Field labels / name / id / submit control — from the actual page. It's ok to ask user about authorization if it is not clear how to makeit.data-user-role).localStorage/sessionStorage for SPAs — verify with I.executeScript(() => Object.keys(localStorage)) after a manual login. Default cookie fetch/restore silently no-op for token storage.Or MCP run_test against a one-Scenario file that calls login(<role>) then asserts on the post-login marker.
Enable saveToFile: true only after the verification round-trip succeeds — a bad saved session masks a broken login.
Add to before hooks (if applied to all tests in suite) or to exact tests in syute
Before(({ login }) => login())
login was declared in auth plugin configuration
Run real, not dry:
npx codeceptjs run --grep '<scenario>' --debug
Only after question 3 is answered. Name users.<key> after whatever splits them in this system; one matching login method per key in steps_file.js.
// keys named after the dimension (role / workspace / provider / …)
users: {
admin: { login: (I) => I.loginAsAdmin() },
workspaceB: { login: (I) => I.loginToWorkspaceB() },
}
Don't parameterise into a single login(key) — the plugin keys sessions by name and explicit methods read better. Switching between sessions in one Scenario: session('<key>') opens a separate browser context (see node_modules/codeceptjs/docs/sessions.md).
When sessions live outside cookies, override fetch and restore:
admin: {
login: (I) => I.loginAsAdmin(),
check: (I) => I.see('Admin', '.navbar'),
fetch: (I) => I.executeScript(() => localStorage.getItem('session_id')),
restore: (I, session) => {
I.amOnPage('/')
I.executeScript((s) => localStorage.setItem('session_id', s), session)
},
}
check(I, session) receives whatever fetch returned — throw inside check to force a fresh login (e.g., when a /me endpoint shows the wrong user).
.env and output/*_session.json. Both leak credentials.node_modules/codeceptjs/lib/plugin/auth.js — JSDoc recipes (cookie / multi-user / local-storage / async / session-validation)node_modules/codeceptjs/docs/auth.md — full referencenode_modules/codeceptjs/docs/sessions.md — session() for multi-user Scenariosnode_modules/codeceptjs/docs/secrets.md — the secret() wrapperProvides CDSS development patterns for drug interaction checking, dose validation, clinical scoring (NEWS2, qSOFA), and alert classification integrated into EMR workflows.
npx claudepluginhub codeceptjs/skills --plugin codeceptjs