Next.js .env.test not loaded during `next dev` or `next start` without explicit NODE_ENV=test

Answer the exact question first

1. Guaranteed loading of .env.test in CI

• Start the dev server with NODE_ENV=test explicitly, e.g. NODE_ENV=test next dev or NODE_ENV=test next start. Next.js uses the NODE_ENV value to decide which .env.* file to load, and .env.test is the highest‑priority file for NODE_ENV=test.
• Alternatively, wrap the command with dotenv‑cli (v6+): dotenv -e .env.test -- next dev. This guarantees the file is sourced before Next.js starts, regardless of the shell’s environment.
• Pin the Next.js version in package.json (e.g. "next": "13.5.6" or "next": "14.0.0-rc.0") so the precedence rules remain stable.

2. Experimental next test runner

• In Next.js 14+, next test sets NODE_ENV=test internally, so .env.test is loaded automatically.
• Because the command is still experimental, it is safer to use the explicit NODE_ENV=test pattern in CI pipelines until the feature is officially released.
• It does not provision test databases or mock external OAuth providers; you still need to set up those mocks separately.

3. Verifying Server Actions use the test credentials

• Create a minimal Server Action that returns or logs the value of the secret, e.g.:

// app/api/secret/route.js
export const GET = async () => {
  const secret = process.env.MY_SECRET;
  console.log('Server Action secret:', secret); // visible in CI logs
  return new Response(secret, { status: 200 });
};

• From your integration test, call this endpoint and assert the response equals the value defined in .env.test.
• Alternatively, log the value inside the action and inspect the CI log for the expected string.

Both approaches confirm that the secret is resolved at request time from .env.test, not from a build‑time fallback.

Diagnostic question for the user

To tailor the recommendation precisely, could you confirm which major Next.js version you are targeting (e.g. 13.x or 14.x)?