DEV Community: Artur Aliakseyeu

Testing NextAuth.js Logins in Cypress: Optimizing Speed & Reliability

Artur Aliakseyeu — Wed, 23 Apr 2025 21:48:18 +0000

Login Strategies for Cypress Tests

In this article, I will demonstrate different approaches to handling authentication in your Cypress tests when using the NextAuth.js credentials provider. We will cover different methods for balancing test reliability with execution speed.

In our examples, we will use a standard email/password login form, authenticating with a hard-coded test user (user@example.com) configured in the NextAuth.js Credentials Provider.

// /auth.config.js

import CredentialsProvider from "next-auth/providers/credentials";

export const authConfig = {
  providers: [
    CredentialsProvider({
      name: "Credentials",
      async authorize(credentials) {
        const user = { id: "1", password: "123", email: "user@example.com" };

        return credentials.email === user.email &&
          credentials.password === user.password
          ? user
          : null;
      },
    }),
  ],
  pages: { signIn: "/login" },
};

// /app/page.js

"use client";

import { signIn } from "next-auth/react";
import { useRouter } from "next/navigation";
import { useState } from "react";

export default function LoginPage() {
  const [email, setEmail] = useState("");
  const [password, setPassword] = useState("");
  const router = useRouter();

  const handleSubmit = async (e) => {
    e.preventDefault();
    const result = await signIn("credentials", {
      email,
      password,
      redirect: false,
    });

    result?.ok && router.refresh();
  };

  return (
    <form onSubmit={handleSubmit}>
      <h1>Login</h1>
      <input
        type="email"
        value={email}
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email"
      />
      <input
        type="password"
        value={password}
        onChange={(e) => setPassword(e.target.value)}
        placeholder="Password"
      />
      <button type="submit">Login</button>
    </form>
  );
}

The simplest and often correct approach is UI-based logins, as they accurately reflect real user behavior and are ideal for end-to-end (E2E) testing. However, if your test suite includes many tests that require authentication, UI-based repeated logins can significantly slow down execution. Below, I will cover several optimization techniques when using NextAuth.js with the credentials provider.

// /cypress/e2e/login.cy.js

describe("Login", () => {
  const credentials = {
    email: "user@example.com",
    password: "123",
  };

  // 1. UI Login
  // Pros: Tests real user journey end-to-end
  // Cons: Requires full render cycle
  it("logs in via UI", () => {
    cy.visit("/");
    cy.contains("Not logged in");
    cy.get('[type="email"]').type(credentials.email);
    cy.get('[type="password"]').type(credentials.password);
    cy.get("button").contains("Login").click();
    cy.contains(`Logged in as ${credentials.email}`).should("be.visible");
  });

  // 2. Direct API Request Login
  // Pros: Fastest method, bypasses UI
  // Cons: Doesn't test actual user flow
  it("logs in via direct API request", () => {
    cy.visit("/");
    cy.contains("Not logged in");

    cy.request({
      method: "GET",
      url: `/api/auth/csrf`,
    }).then((csrfResponse) => {
      return cy.request({
        method: "POST",
        url: `/api/auth/callback/credentials`,
        headers: { "Content-Type": "application/json" },
        body: {
          ...credentials,
          csrfToken: csrfResponse.body.csrfToken,
          json: "true",
        },
      });
    });

    cy.visit("/");
    cy.contains(`Logged in as ${credentials.email}`).should("be.visible");
  });

  // 3. Browser Fetch API Login
  // Pros: Tests auth in browser context with real fetch API
  // Cons: More complex than cy.request, still skips UI
  it("logs in via browser fetch API", () => {
    cy.visit("/");
    cy.contains("Not logged in");

    cy.window().then(async (win) => {
      const csrfResponse = await win.fetch("/api/auth/csrf");
      const { csrfToken } = await csrfResponse.json();

      const loginResponse = await win.fetch("/api/auth/callback/credentials", {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ ...credentials, csrfToken, json: "true" }),
      });

      return loginResponse.json();
    });

    cy.visit("/");
    cy.contains(`Logged in as ${credentials.email}`).should("be.visible");
  });

  // 4. Eval-Based Login
  // Pros: Demonstrates string injection technique
  // Cons: Least readable, potential security concerns
  // Use Case: Only needed when testing code evaluation scenarios
  it("logs in via eval-based approach", () => {
    cy.visit("/");
    cy.contains("Not logged in");

    cy.window().then((win) => {
      return win.eval(`
            (() => {
              const credentials = ${JSON.stringify(credentials)};

              return fetch('/api/auth/csrf')
                .then(r => r.json())
                .then(({ csrfToken }) => 
                  fetch('/api/auth/callback/credentials', {
                    method: "POST",
                    headers: { "Content-Type": "application/json" },
                    body: JSON.stringify({
                      ...credentials,
                      csrfToken,
                      json: "true"
                    })
                  })
                )
                .then(res => res.json())
            })()
          `);
    });

    cy.visit("/");
    cy.contains(`Logged in as ${credentials.email}`).should("be.visible");
  });
});

For most projects, you'll primarily use either UI login (for full end-to-end tests) or API login (for faster tests). The other methods are just examples. To make testing easier, move your login code into Cypress custom commands - this way you can reuse the same login logic across all your tests, keeping them clean and simple.

// /cypress/support/commands.js

Cypress.Commands.add("signIn", (email, password) => {
  cy.request("/api/auth/csrf").then((response) => {
    return cy.request({
      method: "POST",
      url: "/api/auth/callback/credentials",
      body: {
        email,
        password,
        csrfToken: response.body.csrfToken,
        json: "true",
      },
    });
  });
  cy.visit("/");
  cy.contains(`Logged in as ${email}`).should("be.visible");
});

Now you can reuse the login command across all your tests

  it('logs in via custom command', ()=> {
    cy.signIn('user@example.com', '123')
  })

Hope this helps! Full code example:
https://github.com/AlekseevArthur/next-auth-cypress

Integration Tests using Cypress Next.js and Prisma

Artur Aliakseyeu — Mon, 17 Mar 2025 22:10:44 +0000

In this article, I’ll walk you through setting up a Next.js + Prisma + Cypress testing environment. My goal is to keep things as simple as possible, so we’ll use SQLite as the database and React with inline styles for the frontend.

Create a New Next.js Project

Run the following command to create a Next.js app:

npx create-next-app@latest

Press Enter on all prompts to accept the default settings. We’ll be using JavaScript (not TypeScript) and won’t include Tailwind CSS.

Once the setup is complete, open the project in your IDE (e.g., VS Code).

Install Prisma

Next, install Prisma as a development dependency:

npm install prisma --save-dev

Then, initialize Prisma with SQLite as the database provider:

npx prisma init --datasource-provider sqlite

Configure the Database

After running the command, a .env file will be created in your project. Open it and you’ll see the database connection string:

DATABASE_URL="file:./dev.db"

This tells Prisma to use a local SQLite database file (dev.db).

Define the Database Schema

Open the prisma/schema.prisma file and replace its contents with the following:

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "sqlite"
  url      = env("DATABASE_URL")
}

model Book {
  id     Int     @id @default(autoincrement())
  title  String  @unique
  author String?
}

This defines a simple Book model with:

An id that auto-increments.
A title field that must be unique.
An optional author field.

Run Initial Migration

To apply the schema to your database, run:

npx prisma migrate dev --name init

This will create the database file (dev.db) and apply the initial schema.

Create Server Actions for Books

First, create a new file to handle database interactions:

/lib/actions.js

'use server';

import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export const createBook = async (data) => {
  return await prisma.book.create({ data });
};

export const getBooks = async () => {
  return await prisma.book.findMany({});
};

export const deleteBook = async (id) => {
  return await prisma.book.delete({ where: { id } });
};

Clean Up Next.js Default Files

To simplify the project, delete all files inside the /app/ directory except page.js and layout.js.

Create a Simple Books Interface

/app/books.jsx

'use client';

import { createBook, deleteBook } from '@/lib/actions';
import { useRouter } from 'next/navigation';
import { useState } from 'react';

const Book = ({ book, destroy }) => (
  <li>
    <button onClick={destroy}>X</button> &nbsp;
    <b>Title:</b> {book.title}, <b>Author:</b> {book.author}
  </li>
);

const Books = ({ books }) => {
  const [title, setTitle] = useState('');
  const [author, setAuthor] = useState('');
  const [error, setError] = useState(false);
  const { refresh } = useRouter();

  const create = async () => {
    try {
      await createBook({ title, author });
      setError(false);
      refresh();
    } catch (e) {
      setError(true);
    }
  };

  const destroy = async (id) => {
    await deleteBook(id);
    refresh();
  };

  return (
    <main>
      <div>
        <input onChange={(e) => setTitle(e.target.value)} name="title" />
        <label> Title </label>
      </div>
      <div>
        <input onChange={(e) => setAuthor(e.target.value)} name="author" />
        <label> Author </label>
      </div>
      {error && <p style={{ color: 'red' }}>Invalid data provided</p>}
      <br />
      <button onClick={create}>Add new book</button>
      <ul>
        {books.map((book) => (
          <Book book={book} destroy={() => destroy(book.id)} key={book.id} />
        ))}
      </ul>
    </main>
  );
};

export default Books;

Connect UI to the Server

/app/page.js

import { getBooks } from '@/lib/actions';
import Books from './books';

const Home = async () => {
  const books = await getBooks();

  return (
    <>
      <h1>Books</h1>
      <Books books={books} />
    </>
  );
};

export default Home;

Update the Root Layout

/app/layout.js

export default function Layout({ children }) {
  return (
    <html lang="en">
      <body>{children}</body>
    </html>
  );
}

Running the Application

To start your app, run the following command:

npm run dev

This will launch your Next.js application at http://localhost:3000.

In this simple form, you can easily add and remove books. The model makes sure the title is unique and isn’t left blank. If anything goes wrong, you’ll see an error message.

Installing and Setting Up Cypress

To add Cypress to your project, run the following command:

npm install cypress --save-dev

Next, initialize Cypress and generate the default files and folders by running:

npx cypress open

When the Cypress window appears:

Select E2E Testing as your default configuration.
Click Continue to confirm the setup.

Once the setup is complete, close both the Next.js development server and the Cypress window for now.

Setting Up the Test Environment

To ensure our tests run safely and efficiently, setting up a dedicated test environment is essential. Using a separate test database helps protect your development data from accidental changes, as tests often create, update, or delete records. This isolation also ensures tests start with a clean state, making them more consistent and reliable.

Step 1: Install dotenv-cli

We'll use dotenv-cli to manage environment variables for our test setup.

Run the following command:

npm install dotenv-cli --save-dev

Step 2: Create a .env.test File

Next, create a new file called .env.test in your project's root directory.

Add the following content to define your test database URL:

DATABASE_URL="file:./test.db"

Since we're using SQLite, this configuration points to a separate database file called test.db — keeping your development data safe.

Creating a Database Cleaner

Since we currently have only one model (Book), we’ll clean just that for now. As more models are added, this cleaner can be expanded.

Create the file /cypress/tasks/clean.js:

const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient();

const clean = async () => {
  return await prisma.book.deleteMany({});
};

module.exports = clean;

Since we don’t use TypeScript, we must follow the CommonJS module system (e.g., module.exports) instead of ES module syntax (e.g., export default).

Creating a Test Data Factory

We'll create a simple task for adding test data. In our tests, we'll pass an object to this task to generate the necessary database entities.

Create the file /cypress/tasks/createTestBook.js:

const { PrismaClient } = require('@prisma/client');

const prisma = new PrismaClient();

const createTestBook = async ({
  title = 'Death Note',
  author = 'unknown',
} = {}) => {
  return await prisma.book.create({
    data: { title, author },
  });
};

module.exports = createTestBook;

Adding Tasks to Cypress Configuration

Now, let’s register these tasks in the Cypress config file.

/cypress.config.js:

const { defineConfig } = require("cypress");
const clean = require('./cypress/tasks/clean');
const createTestBook = require('./cypress/tasks/createTestBook');

module.exports = defineConfig({
  e2e: {
    baseUrl: 'http://localhost:3001',
    setupNodeEvents(on, config) {
      on('task', {
        clean,
        createTestBook,
      });
    },
  },
});

Adding Scripts to package.json

We need some helpful scripts to simplify the process of:

Running the server on a separate port with the test environment.
Running Cypress tests.
Applying migrations on the test database.

In your package.json, add the following scripts:

"test:cypress": "dotenv -e .env.test -- cypress open",
"test:server": "dotenv -e .env.test -- next dev -p 3001",
"test:migrate": "dotenv -e .env.test -- npx prisma migrate deploy"

Creating the Test Database

Finally, run the following command to apply your migrations to the test database:

npm run test:migrate

This will create the test.db file, ensuring your test environment is properly configured.

Running the Test Server and Cypress

We need to run the test server and Cypress simultaneously. To do this, open two separate terminals and run the following commands:

npm run test:server

npm run test:cypress

Creating the First Test

Now let's write our first Cypress test.

Create the file /cypress/e2e/books.cy.js and add the following code:

describe('Book', () => {
  beforeEach(() => {
    cy.task('clean')
    cy.task('createTestBook')
    cy.task('createTestBook', { title: 'Memoirs of a Geisha' })
    cy.visit('/')
  })

  it('can be created', () => {
    cy.get('[name="title"]').type('Necronomicon')
    cy.get('[name="author"]').type('Abdul Alhazred')
    cy.contains('Add new book').click()
    cy.contains('Title: Necronomicon').should('exist')
  })
})

What Happens in This Test?

The test database is cleaned before each test run.
Two books are created — one with the default name and one titled Memoirs of a Geisha.
The test visits the homepage.
It types a new book's title and author.
The new book is added to the database, and the test checks that it’s displayed on the page.

Running the Test

With both the test server and Cypress running, you should see something like this:

That’s it — it works!

Adding More Tests

Now let's expand our test suite by adding two more specs — one to test invalid input and another to test book deletion.

Here’s the updated /cypress/e2e/books.cy.js file:

describe('Book', () => {
  beforeEach(() => {
    cy.task('clean')
    cy.task('createTestBook')
    cy.task('createTestBook', { title: 'Memoirs of a Geisha' })
    cy.visit('/')
  })

  it('can be created', () => {
    cy.get('[name="title"]').type('Necronomicon')
    cy.get('[name="author"]').type('Abdul Alhazred')
    cy.contains('Add new book').click()
    cy.contains('Title: Necronomicon').should('exist')
  })

  it('can be deleted', () => {
    cy.contains('X').click()
    cy.contains('Title: Death Note').should('not.exist')
    cy.contains('X').click()
    cy.contains('Title: Memoirs of a Geisha').should('not.exist')
  })

  it('cannot be created with an invalid title', () => {
    cy.get('[name="title"]').type('Death Note')
    cy.contains('Add new book').click()
    cy.contains('Invalid data provided').should('exist')
  })
})

So our tests check the following things:

Book Creation: Verifies that a new book can be added successfully.
Book Deletion: Ensures books can be removed from the database.
Invalid Input Handling: Confirms that attempting to create a book with an existing title shows an error message.

Running the Tests

With both the test server and Cypress running, check the Cypress UI to confirm that all tests pass successfully.

Wrapping Up

In this article, we’ve built a simple yet effective testing setup using Next.js, Prisma, and Cypress. While this is a basic configuration, it provides a solid foundation that can be expanded to meet your project's specific needs.

Here you can see the repository - https://github.com/AlekseevArthur/next-prisma-cypress