DEV Community: Alimur Razi Rana

Singleton, Scoped, and Transient: What They Actually Mean for Your DbContext

Alimur Razi Rana — Wed, 24 Jun 2026 10:37:18 +0000

Anyone who has worked with dependency injection in .NET, might have registered something like this:

builder.Services.AddDbContext<AppDbContext>(options =>
    options.UseSqlServer(connectionString));

It works. app runs. But why does AddDbContext default to Scoped, and what would break if it didn't?

Let's find out — by breaking it on purpose.

The three lifetimes

Before touching any code, here's what each lifetime actually promises:

Transient — A new instance is created every single time it's requested. Ask for it twice in the same method, and get two different instances.

Scoped — One instance is created per scope, and reused for every request within that scope. In a web app, a scope is one HTTP request — so everything inside that request shares the same instance. The next request gets a fresh one.

Singleton — Exactly one instance, ever, for the entire lifetime of the app. Every request, every user, every caller — all sharing that one object, forever, until the app shuts down.

That's the theory. Now let's watch it actually happen.

Setting up a DbContext that tells us who it is

The trick to seeing lifetime behavior instead of just reading about it: give the DbContext a fingerprint.

public class AppDbContext : DbContext
{
    public Guid InstanceId { get; } = Guid.NewGuid();

    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
}

Every time a new AppDbContext gets constructed, it stamps itself with a new Guid. If two services end up holding the same InstanceId, we know for certain they got handed the same object — not two copies that look alike.

Two services that both need a database connection

In any real app, most cases never have just one class touching the database. Let's add two:

public class OrderWriter
{
    private readonly AppDbContext _db;
    public OrderWriter(AppDbContext db) => _db = db;

    public void ShowInstance(string label) =>
        Console.WriteLine($"[OrderWriter]     {label} → {_db.InstanceId}");
}

public class InventoryWriter
{
    private readonly AppDbContext _db;
    public InventoryWriter(AppDbContext db) => _db = db;

    public void ShowInstance(string label) =>
        Console.WriteLine($"[InventoryWriter] {label} → {_db.InstanceId}");
}

Both just print which AppDbContext they were handed. Think of these as stand-ins for an OrderRepository and an InventoryService in a real order-processing flow — two unrelated classes that both happen to need the same database context.

We still haven't registered anything with DI yet.

Wiring it up — starting with Singleton

Here's where it gets interesting. Let's register AppDbContext as a Singleton and see what happens across two separate "requests":

var services = new ServiceCollection();

services.AddSingleton<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("SingletonTest").Options;
    return new AppDbContext(options);
});

services.AddTransient<OrderWriter>();
services.AddTransient<InventoryWriter>();

var provider = services.BuildServiceProvider();

I used an in-memory database here on purpose — no real SQL Server needed, so anyone can copy this straight into a console app and run it.

Quick note on OrderWriter and InventoryWriter being Transient: that's deliberate. We want them rebuilt fresh every time, so the only thing that can explain a repeated InstanceId is the DbContext's own lifetime — not some side effect of caching the writer itself.

Simulating two HTTP requests

In a real web app, a "scope" is created automatically for you on every incoming request. In a console app, we have to make that explicit:

using (var requestOne = provider.CreateScope())
{
    var order = requestOne.ServiceProvider.GetRequiredService<OrderWriter>();
    var inventory = requestOne.ServiceProvider.GetRequiredService<InventoryWriter>();
    order.ShowInstance("Request 1");
    inventory.ShowInstance("Request 1");
}

using (var requestTwo = provider.CreateScope())
{
    var order = requestTwo.ServiceProvider.GetRequiredService<OrderWriter>();
    order.ShowInstance("Request 2");
}

Each using block is standing in for one separate incoming HTTP request, completely unrelated to the other.

Run this with the Singleton registration from above, and here's what prints:

[OrderWriter]     Request 1 → 3f1a2b4c-...
[InventoryWriter] Request 1 → 3f1a2b4c-...
[OrderWriter]     Request 2 → 3f1a2b4c-...

Same InstanceId, every single time — even across two completely separate requests.

Why that's actually a problem

In a real app: two unrelated users, hitting your API at the same time, would be sharing one AppDbContext.

DbContext isn't thread-safe. If request 1 and request 2 land close enough together, you'll hit:

InvalidOperationException: A second operation was started on this 
context instance before a previous operation completed.

And even if you never hit that exact exception, there's a quieter problem: EF Core's change tracker never gets cleared. With Scoped, a new DbContext — and therefore a new empty change tracker — gets created for every request. When the request ends, that DbContext gets disposed, and the tracker (along with everything it was holding onto) gets thrown away with it. But in this case, every entity ever loaded by any request stays tracked in that one singleton context, forever, growing without bound for as long as the app runs.

Singleton is wrong here. Let's try the opposite extreme.

Swapping in Transient

Same harness — change the registration line:

services.AddTransient<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("TransientTest").Options;
    return new AppDbContext(options);
});

Run the same two-request simulation, and now you get:

[OrderWriter]     Request 1 → 9c2e7f10-...
[InventoryWriter] Request 1 → 7b44d821-...
[OrderWriter]     Request 2 → a91f3c05-...

Every InstanceId is different — including OrderWriter and InventoryWriter, within the same request.

Why that's also a problem —

Picture OrderService written like this:

public class OrderService
{
    private readonly AppDbContext _db;
    private readonly IInventoryService _inventory;
    private readonly IOrderRepository _repository;

    public OrderService(AppDbContext db, IInventoryService inventory, IOrderRepository repository)
    {
        _db = db;
        _inventory = inventory;
        _repository = repository;
    }

    public async Task PlaceOrderAsync(Order order, OrderItem item)
    {
        await _inventory.ReserveAsync(item.ProductId, item.Quantity);
        await _repository.SaveAsync(order);
        await _db.SaveChangesAsync();
    }
}

ReserveAsync and SaveAsync are written to only stage their changes — no internal SaveChangesAsync() calls — trusting that one final commit at the bottom will save everything. That's the correct pattern, but only if every _db in this picture is the same object.

What happens with Transient

If AppDbContext is registered Transient, OrderService's own constructor gets handed its own fresh instance — call it DbContext#3. That's separate from whatever IInventoryService was given (DbContext#1) and whatever IOrderRepository was given (DbContext#2).

So:

_inventory.ReserveAsync stages its change on DbContext#1.
_repository.SaveAsync stages its change on DbContext#2.
_db.SaveChangesAsync() commits DbContext#3 — which nothing ever touched.

The method runs to completion. No exception. No error. And nothing was saved — because the one context that actually got told to commit was never the one holding any staged changes. The changes inside DbContext#1 and DbContext#2 are simply discarded the moment those objects are disposed, since nobody ever called SaveChangesAsync() on either of them specifically.

Now the one that actually works: Scoped

Last swap:

services.AddScoped<AppDbContext>(_ =>
{
    var options = new DbContextOptionsBuilder<AppDbContext>()
        .UseInMemoryDatabase("ScopedTest").Options;
    return new AppDbContext(options);
});

Run it again:

[OrderWriter]     Request 1 → c450e9a2-...
[InventoryWriter] Request 1 → c450e9a2-...
[OrderWriter]     Request 2 → e702b614-...

Look at that pattern closely — OrderWriter and InventoryWriter share an InstanceId within Request 1, but Request 2 gets a completely different one.

That's exactly the property we need:

Within one request, every service shares one DbContext — one change tracker, one real unit of work. OrderWriter and InventoryWriter can both stage changes and commit them together.
Across requests, nothing leaks. Request 2 starts clean, with no leftover tracked entities from Request 1, and no thread-safety conflict if both requests happen to run at the same time.

Putting it side by side

Lifetime	Within one request	Across two requests	What goes wrong
Singleton	Same instance	Same instance	Thread-safety crashes, unbounded change tracker growth
Transient	Different instances	Different instances	Two services in one request can't share a transaction
Scoped	Same instance	Different instances	Nothing — this is the one that fits

Try it yourself

The full thing runs as a plain console app — no real database required, since we're using EF Core's in-memory provider for the experiment. You'll need:

dotnet add package Microsoft.EntityFrameworkCore.InMemory

Then just swap the single registration line between AddSingleton, AddTransient, and AddScoped, rerun, and watch the GUIDs tell the story. [gist link] Once you've seen all three side by side like this, the rule stops being something you memorized and starts being something you actually understand: match the lifetime to how long the state inside the object is supposed to live. A DbContext should live exactly as long as one unit of work — which, in a web app, is exactly one request. That's not a coincidence. That's the entire reason Scoped exists.

That covers Scoped pretty thoroughly. But Scoped isn't the only lifetime that earns its place — Singleton and Transient each have a scenario where they're not just "safe," they're the better choice than the other two. Let's look at one real example of each.

When Singleton is the right call

Use Singleton for stateless objects, require heavy initialization, or hold global application state. Common examples:

Caching services
Configuration providers
Logging utilities
Background workers and hosted services

When to avoid Singleton:

Thread-unsafe state — if multiple requests can hit the same instance at the same time, concurrent modifications to mutable data will cause bugs that are hard to reproduce.
Captive dependencies — never inject a shorter-lived service (Scoped or Transient) into a Singleton. Doing so forces that shorter-lived service to live far longer than it was designed to, which is exactly the bug our AppDbContext experiment above demonstrated: a Scoped DbContext trapped inside something longer-lived stops behaving like a per-request unit of work and starts leaking state across requests instead.

Picture an app-wide pricing settings provider — tax rates, currency exchange rates, feature flags — loaded once from configuration or a slow-changing table, then read over and over by every request that calculates a price.

If this were Scoped, every single request would re-read config and rebuild that exchange-rate data from scratch — paying the same cost over and over for a result that never changes between requests. Transient would be worse, potentially rebuilding it multiple times within one request if several services injected it.

When Transient is the right call

Use Transient when:

The service is stateless — the class doesn't hold or track data across multiple calls.
You're building lightweight utilities — simple validators, formatters, or data mappers are a natural fit.
The service isn't thread-safe — since you get a fresh instance every time, you sidestep the concurrency issues that come from sharing one object across multiple threads.
You need to avoid state contamination — you want one operation's execution to never leak data into another operation's execution, even within the same request.

When not to use Transient:

Heavily used dependencies — since the container builds a new object every single time, excessive use of Transient services increases allocations and adds pressure on the garbage collector, which can hurt performance at scale.
When sharing context is required — if multiple services need to work on the same unit of work at the same time (Entity Framework's DbContext being the textbook case), Transient breaks that sharing apart. That's exactly what we watched happen in the experiment above — use Scoped instead.

Now picture a report builder that accumulates lines as it works — say, one service builds the text for an invoice summary, and a separate, unrelated service builds the text for a shipping label. These aren't two pieces of one shared document; they're two completely independent outputs that just happen to use the same kind of builder. Transient guarantees each service gets its own instance, starting from a clean slate, so the invoice service's lines never show up inside the shipping service's result, and vice versa.

The pattern across all three

Lifetime	What actually justifies it	What goes wrong with the wrong choice
Singleton	Holds no per-request data; nothing mutates after construction	Scoped/Transient would rebuild expensive, identical state on every request for no benefit
Scoped	Wraps a per-request unit of work (like `DbContext`) that multiple services need to share	Singleton leaks state across users; Transient splits one logical operation into disconnected pieces
Transient	Mutates its own state mid-operation, and that state must never be shared between callers	Scoped or Singleton would let one caller's leftover state corrupt another's result

Every lifetime decision in this article comes down to the same one question, asked about the specific object in front of you: what does this object store on itself, who else might be holding the same instance at the same time, and what would happen if they were? Answer that honestly for any service in your own app, and the right registration call — AddSingleton, AddScoped, or AddTransient — stops being a guess.

React Doesn't Need Node.js — Until It Does

Alimur Razi Rana — Mon, 08 Jun 2026 16:44:03 +0000

The Truth Nobody Tells You When You Start React

Most React tutorials for beginners start the same way

"First, install Node.js..."

And every beginner obeys without question. Most of them never challenge it. It's just accepted as part of the ritual.

But here's the thing — React doesn't actually need Node.js to work.

And understanding why that's true, and where it stops being true, will completely change how developers think about the entire React ecosystem — including Vite, Next.js, and npm itself.

Let's start with a proof.

Part 1: React With Zero Node.js

Create a plain .html file on your desktop. Paste this in:

<!DOCTYPE html>
<html>
  <head>
    <title>React, no Node.js</title>
  </head>
  <body>

    <div id="root"></div>

    <!-- React from CDN -->
    <script src="https://unpkg.com/react@18/umd/react.development.js"></script>
    <script src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script>

    <!-- Babel to handle JSX in the browser -->
    <script src="https://unpkg.com/@babel/standalone/babel.min.js"></script>

    <script type="text/babel">
      function App() {
        const [count, setCount] = React.useState(0);
        return (
          <div>
            <h1>Hello from React!</h1>
            <p>Count: {count}</p>
            <button onClick={() => setCount(count + 1)}>Click me</button>
          </div>
        );
      }

      ReactDOM.createRoot(document.getElementById('root')).render(<App />);
    </script>

  </body>
</html>

Double-click the file. Open it in your browser.

It works. State works. JSX works. React works.

No Node.js. No npm. No terminal. No installation.

Just a file and a browser.

This isn't a trick or a hack. This is how React was used in its early days. React is, at its core, just a JavaScript library — the same as jQuery or Lodash. It can be loaded with a <script> tag like anything else.

So if that's true... why does every guide tell you to install Node.js?

Part 2: Where the CDN Approach Breaks Down

The CDN approach works perfectly for small experiments. But the moment the app grows beyond a single file, it hits its real limitations.

First, a common misconception worth clearing up:

Modern browsers actually support ES module imports natively:

<script type="module">
  import Header from './Header.js'
  import Footer from './Footer.js'
</script>

So imports themselves aren't the problem. The real limitations are deeper than that.

1. JSX Needs Compilation

Browsers understand JavaScript. They do not understand JSX:

// ❌ Browser has no idea what this is
function App() {
  return <h1>Hello</h1>
}

// ✅ Browser only understands this
function App() {
  return React.createElement("h1", null, "Hello")
}

Every JSX file needs to be compiled into plain JavaScript before a browser can run it. Native ES modules don't solve this — the browser still can't parse the JSX syntax itself.
This compilation step is handled by different tools depending on setup:

Babel — the original JSX compiler, still widely used in plain React projects
Vite — the popular choice for modern plain React projects
Next.js SWC — Next.js ships with its own built-in compiler

2. npm Packages Aren't ES Module Compatible Out of the Box

Most npm packages are written in CommonJS format — Node.js's own module system:

// CommonJS — how most npm packages are written
const axios = require('axios')
module.exports = something

This is completely different from ES modules:

// ES Modules — what browsers understand
import axios from 'axios'
export default something

Browsers cannot run CommonJS. A bundler is needed to convert and reconcile these formats before they reach the browser.

3. Dependency Management Becomes a Nightmare

Want to use axios? You'd manually find its CDN link. Then manually find CDN links for all of axios's dependencies. Then their dependencies. A single real-world package can pull in dozens of sub-dependencies — tracking all of them by hand is completely unworkable.

4. Performance Suffers With Many Module Files

Even if everything was ES module compatible, loading 200 separate JavaScript files means 200 separate network requests — each with its own overhead. A bundler combines them into one or a few optimized files, which loads faster.

Part 3: What Node.js Actually Is

Before understanding why Node.js solves these problems, you need to understand what Node.js actually is — because most developers use it for years without knowing this.

Operating system cannot run JavaScript.

OS can run Python (if installed). It can run compiled C++ binaries. But JavaScript? No. Most operating systems don't include a built-in JavaScript runtime that can execute JavaScript files directly.

Only two environments (currently, there are different alternatives like Deno or Bun, but for simplicity, exclude these environments) have been able to execute JavaScript:

1. The Browser
   → Chrome, Firefox, and Safari all have a built-in JS engine
   → Chrome uses V8 (built by Google)
   → Firefox uses SpiderMonkey

2. Node.js
   → Takes Chrome's V8 engine
   → Strips out the browser parts (DOM, window, etc.)
   → Adds OS-level access (file system, network, processes)
   → Runs as a standalone program on your computer

That's literally all Node.js is. It's Chrome's JavaScript engine, liberated from the browser and given the ability to talk to your operating system.

Ryan Dahl, who created Node.js in 2009, had one core insight:

"JavaScript is already a great language. Why does it only run in browsers? What if it could run anywhere?"

So when you install Node.js, you're essentially installing a JavaScript interpreter directly onto your machine — the same engine that powers Chrome, just without the browser.

This is why npm packages need Node.js.

npm packages are JavaScript files. OS can store them just fine — it's great at storing files. But it cannot execute them. It has no JavaScript engine. Node.js provides that engine. Without it, those JavaScript files just sit there on your disk doing nothing.

Part 4: What npm Actually Solves

After Node.js, let's talk about npm — because it's far more than just a package downloader.

When you run npm install axios, npm doesn't just download axios. It:

1. Downloads axios
2. Reads axios's list of dependencies
3. Downloads those dependencies
4. Reads THEIR dependencies
5. Downloads those too
6. Resolves any version conflicts across the whole tree
7. Builds a complete, working dependency graph
8. Stores everything in node_modules

This process — called dependency resolution — is genuinely complex. Packages depend on other packages, which depend on other packages, which might conflict with each other's version requirements. npm handles all of this automatically.

Without npm, developers would need to do this by hand. For a real project with dozens of dependencies, each with their own sub-dependencies, that would be thousands of files to track manually. It would be completely unworkable.

And critically — npm itself is built on Node.js. It needs Node.js to run the resolution logic, download packages, execute install scripts, and manage the entire node_modules directory.

So the chain is clear:

You need npm
  → npm needs Node.js to run
    → Node.js provides the JS engine
      → JS engine executes npm's logic
        → npm manages your packages
          → packages can now be used in your app

Remove Node.js from this chain and the whole thing collapses.

Part 5: In Production, Node.js Disappears (For Plain React)

Here's something that surprises many developers.

When you run npm run build in a plain React + Vite project, Vite does all its work and produces a /dist folder:

/dist
  index.html
  assets/
    main.abc123.js     ← plain JavaScript, no JSX
    styles.abc123.css  ← plain CSS
    logo.abc123.png    ← optimized image

These are completely static files. Plain HTML, CSS, and JavaScript that any browser understands natively.

At this point, Node.js is completely out of the picture. You can take this /dist folder and host it on:

AWS S3
GitHub Pages
Netlify
Cloudflare Pages
A basic Apache server
Literally any file hosting service

No Node.js required. No server running. No ongoing processes. Just files being served.

Node.js was only needed during development — to run the JSX compiler, manage packages, and transform your code. Once the build is done, it has no role left.

Part 6: Next.js Changes Everything

Everything we've covered so far describes plain React — a client-side application where the browser does all the rendering work.

Next.js fundamentally changes this model.

How Plain React Renders

User visits your site
        ↓
Server sends an almost empty HTML file:

<html>
  <body>
    <div id="root"></div>  ← nothing here
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser downloads bundle.js (can be 1-2MB)
        ↓
JavaScript runs, React builds the UI
        ↓
User finally sees content

The server does almost nothing. The browser does all the work. This means:

Users on slow connections wait a long time before seeing anything
Search engines see an empty page — bad for SEO
The user's device carries all the rendering cost

How Next.js Renders

User visits react site
        ↓
Request hits the Next.js SERVER (Node.js running live)
        ↓
Server executes React components
        ↓
Produces complete HTML with actual content:

<html>
  <body>
    <div id="root">
      <h1>Your Product Name</h1>   ← already here
      <p>Price: $49</p>            ← already here
      <button>Buy Now</button>     ← already here
    </div>
    <script src="bundle.js"></script>
  </body>
</html>
        ↓
Browser receives full HTML instantly
        ↓
User sees content immediately ✅
        ↓
React "hydrates" — attaches event listeners
        ↓
App becomes interactive ✅

The key difference: the server does the rendering work before the browser gets involved.

The Browser Has No Idea

The browser doesn't know — and doesn't care — whether it received HTML from a Next.js server, a plain React build, a WordPress site, or hand-written HTML. It just renders what it gets.

The difference is entirely in what the server sends. Next.js sends richer, fuller HTML. Plain React sends almost nothing and lets the browser figure it out.

Node.js Stays Alive in Production

This is the critical difference from plain React.

In a plain React app, Node.js is a development-only tool that disappears after the build.

In Next.js, Node.js runs permanently in production ( Next.js can also run a project with little or no traditional Node server, depending on how the application is configured ) — processing every user request, rendering components on the server, fetching data from databases, and generating HTML in real time.

Plain React:
Node.js role → Development only → Gone after build

Next.js:
Node.js role → Development AND Production → Always running

This is why Next.js cannot be deployed to a static file server (unless exported it as fully static). It needs a live Node.js process running 24/7 to handle incoming requests.

Found this useful? Share it with the developer who just ran npm install without knowing why.

Guide to Integrating Cypress and Cucumber with Angular

Alimur Razi Rana — Sun, 03 Mar 2024 08:57:39 +0000

In software engineering, despite developers' confidence in their code, comprehensive testing is indispensable for determining its efficacy. Developers and QA engineers must navigate through diverse testing phases to ascertain the comprehensive functionality of their applications. Two widely embraced methodologies for this purpose, are End-to-End (E2E) testing and Behavior-Driven Development (BDD) testing.

While Cypress and Cucumber are favored tools for such testing, integrating them poses challenges due to their differing configurations. If developers try to work with typescript, it creates one extra configuration layer. Cypress’s configuration changed a lot from their pre-10 version. So maybe this blog can help others when they need to work later.

Numerous tutorials and blogs cover the importance and procedures of E2E testing or BDD testing. However, This article focuses specifically on integration procedures for these testing methodologies.

Now it's time to make our hands dirty. Cypress and cucumber will be integrated into an angular project which by default maintains typescript. So ensure that you have already installed Node.js, npm, and ng package in your work environment.

Create a new angular project. ng new angular-cypress-cucumber
E2E testing needs your project running, so you need to run this angular project by npm start
Install @cypress/schematic package, this will help the angular project to run with Cypress. ng add @cypress/schematic

During installation, @cypress/schematic automatically includes necessary npm packages. Additionally, it generates a Cypress configuration file, "cypress.config.ts" and adjusts the "angular.json" configuration file accordingly. Furthermore, it establishes a dedicated "cypress" sub-directory, including sample test files to help the developer get started.

We will execute test cases on a user list page. On this basic listing page, we can envision below scenarios:

Initially, the page will display no users.
Following the click of the "Get Users" button, an API call will be triggered. If the API returns a valid response, the list will appear.
In case of an error returned by the API, the page will remain unchanged.

Now it is time for BDD
npm i @badeball/cypress-cucumber-preprocessor @cypress/webpack-preprocessor -d

Replace the whole cypress.config.ts with below configuration content

import { defineConfig } from 'cypress';
const webpack = require("@cypress/webpack-preprocessor");
const preprocessor = require("@badeball/cypress-cucumber-preprocessor");

async function setupNodeEvents(on, config) {
  await preprocessor.addCucumberPreprocessorPlugin(on, config);
  on(
    "file:preprocessor",
    webpack({
      webpackOptions: {
        resolve: {
          extensions: [".ts", ".js"],
        },
        module: {
          rules: [
            {
              test: /\.feature$/,
              use: [
                {
                  loader: "@badeball/cypress-cucumber-preprocessor/webpack",
                  options: config,
                },
              ],
            },
          ],
        },
      },
    })
  );
  return config;
}

export default defineConfig({
  e2e: {
    'baseUrl': 'http://localhost:4200', // this will be the default page for e2e testing
    specPattern: ["**/e2e/**/*.feature"], // all e2e test file’s name should be in this pattern
    setupNodeEvents
  },
  component: {
    devServer: {
      framework: 'angular',
      bundler: 'webpack',
    },
    specPattern: '**/*.cy.ts'
  }
})

The configuration file facilitates the preprocessing of Cucumber-generated test cases, preparing them for execution by Cypress. Furthermore, it adjusts the spec locations, allowing Cypress to discover .feature files for test execution. These feature files encapsulate BDD test cases written in the Gherkin syntax.

In the package.json file add this new property too

"cypress-cucumber-preprocessor": {
    "stepDefinitions": "cypress/e2e/bdd-cucumber/step-defination/*.step.cy.ts"
},

Within the existing cypress/e2e directory, create a new folder named bdd-cucumber and create another folder inside bdd-cucumber named features. Navigate to the cypress\e2e\bdd-cucumber\features directory and create a new file named user-page.feature. As previously noted, Cucumber or BDD operates with the Gherkin language. The features within this folder will adhere to its syntax.

user-page.feature

Feature: User List functionality
  Background: Prepare user page
    Given I am on the user page

  Scenario: Users appear in UI when API call succeeds
    When I click the "Get Users" button
    Then A api call will be requested with valid response
    And user list will be appear on successful api request

  Scenario: Users do not appear in UI when API call fails
    When I click the "Get Users" button to check failed response
    Then A api call will be requested with failed response
    And User list will not appear on failed api request

You can also install highlight-cucumber vscode extension to colorize those features.

In the bdd-cucumber folder create another folder named step-defination . Cypress test files will be added to this folder.

user-page.step.cy.ts

import {
  Given,
  When,
  Then,
} from '@badeball/cypress-cucumber-preprocessor';

const apiUrl = 'https://jsonplaceholder.typicode.com/users';

Given('I am on the user page', () => {
  cy.visit('/');
});

When('I click the "Get Users" button', () => {
  cy.intercept('GET', apiUrl).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with valid response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.response?.statusCode).to.eq(200);
  });
});

Then('user list will be appear on successful api request', () => {
  cy.get('span.user-name').its('length').should('be.greaterThan', 0);
});

When('I click the "Get Users" button to check failed response', () => {
  cy.intercept('GET', apiUrl, { forceNetworkError: true }).as('getUserList');
  cy.contains('Get User').click();
});

Then('A api call will be requested with failed response', () => {
  cy.wait('@getUserList').then((interception) => {
    expect(interception.request.url).to.eq(apiUrl);
    expect(interception.error).to.exist;
    expect(interception.error?.message).to.eq('forceNetworkError called');
  });
});

Then('User list will not appear on failed api request', () => {
  cy.get('span.user-name').should('not.exist');
});

As we have already written our test cases, the next step is to implement a user list page. For simplicity, the Angular project comprises solely html and typescript code to retrieve user data via API.

app.component.ts

import { Component } from '@angular/core';
import { HttpClient } from '@angular/common/http';

type User = {
  name: string;
}

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})

 export class AppComponent {
  title = 'angular-cypress-cucumber';
  url = "https://jsonplaceholder.typicode.com/users";
  users: User[] = [];
  constructor(private httpClient: HttpClient) {}

  getUsers() {
    this.httpClient.get<User[]>(this.url).subscribe(
      {
        next: (res) => {
          this.users = res;
        },
        error: (err: any) => {
          alert("Something went wrong!");
         },
        complete: () => { }
      }
    );
  }
}

app.component.html

<div>
  <button (click)="getUsers()">Get User</button>
  <ul>
    <li *ngFor="let user of users">
      <span class="user-name">{{user.name}}</span>
    </li>
  </ul>
</div>

Now navigate to the project's directory, and run the command npm run cypress:open. Before that, ensure that the angular project is running in http://localhost:4200 which is declared as the base URL in the cypress configuration.

Github Link