DEV Community: Alok Kumar

Part 1 — What Actually Happens When Code Runs

Alok Kumar — Wed, 19 Aug 2026 21:52:08 +0000

When we write:

const result = add(10, 20);

it feels like the computer simply "runs the code."

But the CPU doesn't understand JavaScript. There are several layers between the code we write and the hardware actually executing instructions.

That's what I wanted to understand first.

From JavaScript to the CPU

In Node.js, JavaScript is handled by V8, the JavaScript engine.

A simplified view looks like this:

JavaScript
    ↓
V8
    ↓
Bytecode
    ↓
JIT compilation
    ↓
Machine instructions
    ↓
CPU

V8 doesn't simply "interpret JavaScript" or "compile JavaScript" once and forget about it.

It can start with bytecode and progressively compile frequently executed ("hot") code into more optimized machine code.

Eventually, the CPU is executing instructions that operate at a much lower level than the JavaScript we originally wrote.

What does the CPU actually do?

At its core, a CPU repeatedly executes instructions.

A simplified mental model is:

Fetch → Decode → Execute → Repeat

The CPU has several important pieces involved in this process.

Registers are tiny, extremely fast storage locations inside the CPU. They're used to hold values the CPU is actively working with.

The ALU (Arithmetic Logic Unit) performs many arithmetic and logical operations.

The Program Counter (PC) keeps track of where the next instruction comes from.

And the CPU runs according to a clock, measured in GHz. A 3 GHz CPU has roughly 3 billion clock cycles per second, but that does not mean it executes 3 billion instructions per second. Different instructions and architectures have different costs.

Modern CPUs are far more sophisticated than this simplified model, using pipelining, multiple execution units, branch prediction, out-of-order execution, and more. But the basic model is enough to start reasoning about performance.

The CPU doesn't get everything from RAM

One of the most important things I learned here is that where data lives matters.

A simplified hierarchy looks like:

Registers
    ↓
L1 Cache
    ↓
L2 Cache
    ↓
L3 Cache
    ↓
RAM
    ↓
SSD
    ↓
Network

This isn't a literal pipeline that every access travels through. It's a hierarchy of increasingly larger but generally slower resources.

Registers are extremely close to the execution units and very limited in size.

Caches sit between the CPU and RAM and keep frequently or recently used data closer to the CPU.

RAM is much larger, but accessing it takes significantly more time than accessing a register or cache.

This leads to a fundamental performance idea:

The closer the data is to the CPU, the cheaper it generally is to access.

Cache hits, misses and locality

Suppose the CPU needs some data.

If it's already in a cache:

CPU → Cache → Data found

that's a cache hit.

If it isn't:

CPU → L1 → L2 → L3 → RAM

the CPU may have to go farther to find it. That's a cache miss.

This is why locality matters.

Temporal locality: if we accessed something recently, we're likely to access it again.

Spatial locality: if we accessed one memory location, we're likely to access nearby locations.

For example:

for (let i = 0; i < array.length; i++) {
    sum += array[i];
}

accesses elements sequentially. That pattern is generally friendlier to caches than jumping randomly around memory.

This is also why two pieces of code with the same O(n) complexity can have very different real-world performance.

Latency vs Bandwidth

These two terms show up everywhere in computer systems.

Latency is essentially:

How long until I get the result?

Bandwidth is:

How much data can I transfer per unit of time?

A system can have high bandwidth but still have significant latency.

We'll encounter this distinction again with RAM, disks, networks, and databases.

What about numbers?

At the lowest level, computers work with bits:

0 or 1

Eight bits make a byte.

A fixed number of bits means a fixed number of representable values. That's why we have concepts like:

signed vs unsigned integers
integer overflow
limited precision

Floating-point numbers introduce another interesting problem.

JavaScript's Number uses IEEE-754 double-precision floating-point representation. Not every decimal fraction has an exact binary representation.

That's why:

0.1 + 0.2

produces:

0.30000000000000004

It's not that JavaScript can't do basic addition. We're seeing the consequences of how numbers are represented in binary with finite precision.

CPU-bound vs I/O-bound

Another useful distinction is whether our program is primarily computing or waiting.

A huge calculation:

for (let i = 0; i < 5_000_000_000; i++) {
    // heavy computation
}

is CPU-bound. The CPU spends most of its time doing work.

But something like:

await fetch("/users");

is largely I/O-bound. The program may spend significant time waiting for the network rather than continuously using the CPU.

This distinction becomes particularly important when we get to Node.js and its event loop.

Putting it all together

So when I run a Node.js function, the mental model I want to have is no longer:

JavaScript → magic → result

but something closer to:

JavaScript
    ↓
V8
    ↓
Bytecode / JIT compilation
    ↓
Machine instructions
    ↓
CPU core
    ↓
Registers
    ↓
Caches
    ↓
RAM

Along the way, performance can be affected by things like:

instruction execution, CPU utilization, memory latency, cache misses, locality, and I/O waits.

And that's the foundation for everything that follows.

Because the next question is obvious:

If multiple programs are running on the same machine, who decides which program gets the CPU, how memory is managed, and how programs interact with hardware?

That's where the Operating System comes in.

Computer Fundamentals: No BS

Alok Kumar — Wed, 19 Aug 2026 21:44:49 +0000

I've been working with software for a few years now, and I've noticed something uncomfortable.

I can build things.

I can work with React, Node.js, databases, APIs, cloud services, and all the usual stuff that comes with being a software engineer.

But if I stop and ask:

"What is the computer actually doing underneath all of this?"

My mental model gets surprisingly fuzzy.

I know the concepts. I've used them. I've probably explained some of them before.

But knowing how to use something and understanding what is actually happening underneath it are two very different things.

And I want to fix that.

Why I'm writing this

This isn't a course, and I'm not writing this as an expert teaching computer science.

These are essentially my notes while rebuilding my computer fundamentals from the ground up.

I'm trying to connect the things I use every day as a software engineer with what is actually happening inside the machine.

Instead of learning concepts because they're on a traditional CS syllabus, I'm starting with a question:

What do I actually need to understand to reason about a production system?

For me, that means being able to look at a system and understand what's happening underneath my code.

Why is something slow?
Where is the bottleneck?
What happens when something fails?
Why does adding more memory help in one situation but not another?
What actually happens when two things execute concurrently?
Why does a database query become slow?
What happens to a simple HTTP request between two machines?

I don't want to just know the answer.

I want the mental model that lets me reason about the answer.

The path I'm taking

I'm roughly following the layers that a typical request passes through:

CPU → Memory → OS → Network → Storage → Concurrency → Distributed Systems

So the series will go through:

1. What Actually Happens When Code Runs

Starting from the bottom: CPU mental model, memory hierarchy, and number representation.

2. Operating Systems

Then moving up into processes, threads, virtual memory, and system calls.

3. Networking: From `fetch()` to Packets

Following a simple network request through network fundamentals, IP, TCP, DNS, and HTTP.

4. Databases + Storage

Understanding what happens below a database query: memory vs disk, database pages, B-Tree/B+Tree, query execution, transactions, and eventually how these ideas show up in MongoDB and PostgreSQL.

5. Concurrency + Node.js Internals

Connecting the fundamentals to the runtime I actually use: concurrency vs parallelism, Node.js architecture, the event loop, async/await, and race conditions.

6. Distributed Systems Fundamentals

Finally adding multiple machines and all the problems that come with them: load balancing, caching, queues, failures, and CAP theorem.

7. Put Everything Together

And then trying to connect all of these pieces into one mental model.

Something as simple as:

const response = await fetch("/users");

turns out to involve an absurd number of layers underneath it.

That's the part I want to understand.

I'm not sure I'll get everything right on the first attempt.

That's kind of the point.

I'll be writing these as I learn, simplifying things where possible, digging deeper where necessary, and correcting my understanding along the way.

If you're also a software engineer who feels like there's a gap between "I know how to use this" and "I understand what's actually happening", maybe these notes will be useful to you too.

Computer Fundamentals: No BS.

Let's start from the machine.

Unit Testing in React Using Vitest — A Practical Guide

Alok Kumar — Thu, 02 Apr 2026 23:33:16 +0000

In the previous article, we explored the fundamentals of unit testing in JavaScript — what it is, why it matters, and how tools like Jest help automate testing.

In modern frontend development, however, we rarely work with standalone functions alone. We build user interfaces using frameworks like React, where behavior depends on rendering, state changes, user interactions, and asynchronous data.

This is where unit testing in React becomes essential.

What is Unit Testing in React?

Unit testing in React focuses on verifying that individual components behave correctly under different conditions. Instead of testing isolated functions only, we test how components render, respond to user interactions, and display data.

A React component can be considered a unit.

Examples of units in React:

A component
A custom hook
A utility function used inside a component
A form submission handler
A state update logic

In React, unit testing is less about internal implementation and more about observable behavior.

We test things like:

Does the component render correctly?
Does it display the right data?
Does it update the UI after an interaction?
Does it call a function when a button is clicked?
Does it handle loading and error states?

How Unit Testing in React Fits Next to Unit Testing in JavaScript

Unit testing in React builds directly on the same principles as unit testing in JavaScript.

The core idea remains unchanged:

Verify behavior in isolation.

But the type of behavior we verify is different.

Unit Testing in JavaScript

We test:

Functions
Logic
Calculations
Data transformations

Example:

function calculateTotal(price, quantity) {
  return price * quantity;
}

We verify:

expect(calculateTotal(100, 2)).toBe(200);

Unit Testing in React

We test:

Rendering
User interaction
State changes
DOM updates

Example:

render(<Counter />);

fireEvent.click(button);

expect(screen.getByText("1")).toBeInTheDocument();

The Relationship

Think of it like this:

Unit Testing in JavaScript tests logic
Unit Testing in React tests behavior

Both follow the same testing principles:

Isolation
Predictability
Repeatability
Automation

React testing is simply the next layer built on top of JavaScript testing.

Vitest

Vitest is a fast, modern testing framework designed specifically for applications built with Vite. It provides a familiar API similar to Jest while offering better performance and seamless integration with modern frontend tooling.

Vitest is commonly used for:

React applications
Vite projects
Component testing
Unit testing
Integration testing

Why Vitest ?

Vitest solves several problems in modern frontend testing.

It provides:

Fast test execution
Native Vite integration
Built-in mocking
Watch mode
Code coverage
Snapshot testing
Parallel test execution

Most importantly, it allows developers to write tests using a syntax that feels very similar to Jest.

Example:

describe("Counter", () => {
  test("increments count", () => {
    expect(count).toBe(1);
  });
});

If you already know Jest, learning Vitest is straightforward.

Setting Up Vitest in a React Project

Setting up Vitest in a React project is simple, especially when using Vite.

Step 1 — Install Dependencies

npm install --save-dev vitest @testing-library/react @testing-library/jest-dom jsdom

These packages provide:

Vitest — test runner
Testing Library — component testing utilities
jest-dom — better DOM assertions
jsdom — browser environment for tests

Step 2 — Update package.json

{
  "scripts": {
    "test": "vitest",
    "test:watch": "vitest --watch",
    "test:coverage": "vitest --coverage"
  }
}

Step 3 — Configure Vitest

Create:

vitest.config.js

import { defineConfig } from "vitest/config";

export default defineConfig({
  test: {
    environment: "jsdom",
    globals: true
  }
});

What to Test in React

When testing React components, we focus on behavior that users can observe.

Not implementation details.

What to Test

You should test:

Component rendering
User interactions
Conditional rendering
API responses
Form submission
Error handling
Loading states
Function calls

What NOT to Test

Avoid testing:

Internal state directly
Implementation details
Third-party libraries
Styling
Framework behavior

Testing Philosophy

Test the component the way a user interacts with it.

Not the way the code is written.

Core React Testing Examples

Before jumping into examples, let's briefly understand some commonly used testing terms. These utilities appear frequently when writing tests with Vitest and React Testing Library.

render
render mounts a React component into a simulated DOM so it can be tested.

render(<Component />);

screen
screen provides queries to find elements in the rendered DOM.

screen.getByText("Submit");

fireEvent
fireEvent simulates browser events like clicks and input changes.

fireEvent.click(button);

userEvent
userEvent simulates real user interactions more accurately than fireEvent.

await userEvent.click(button);

expect
expect verifies that the result matches the expected behavior.

expect(element).toBeInTheDocument();

describe
describe groups related tests together.

test
test defines an individual test case.

beforeEach
beforeEach runs before every test.
Commonly used to render components or reset state.

afterEach
afterEach runs after every test.
Often used to clean up mocks.

cleanup
cleanup removes rendered components from the DOM after tests.
This prevents tests from interfering with each other.

vi.fn
Creates a mock function.

const mockFn = vi.fn();

vi.mock
Replaces a module with a mock implementation.

Used for APIs and services.

Example Component — Counter

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState(0);

  function handleIncrement() {
    setCount(count + 1);
  }

  return (
    <div>
      <h1 data-testid="count">{count}</h1>

      <button onClick={handleIncrement}>
        Increment
      </button>
    </div>
  );
}

export default Counter;

Example 1 — Testing Component Rendering

import { render, screen } from "@testing-library/react";
import Counter from "./Counter";

test("renders initial count", () => {
  render(<Counter />);

  expect(
    screen.getByTestId("count")
  ).toHaveTextContent("0");
});

Example 2 — Testing User Interaction

import { fireEvent } from "@testing-library/react";

test("increments count when button is clicked", () => {
  render(<Counter />);

  fireEvent.click(
    screen.getByRole("button", {
      name: /increment/i
    })
  );

  expect(
    screen.getByText("1")
  ).toBeInTheDocument();
});

Example 3 — Using beforeEach

import { render, screen } from "@testing-library/react";
import { beforeEach } from "vitest";

describe("Counter", () => {
  beforeEach(() => {
    render(<Counter />);
  });

  test("shows initial count", () => {
    expect(
      screen.getByText("0")
    ).toBeInTheDocument();
  });

  test("increments count", () => {
    fireEvent.click(
      screen.getByRole("button")
    );

    expect(
      screen.getByText("1")
    ).toBeInTheDocument();
  });
});

Example 4 — Testing Function Calls

import { vi } from "vitest";

test("calls handler when clicked", () => {
  const mockFn = vi.fn();

  render(
    <button onClick={mockFn}>
      Click
    </button>
  );

  fireEvent.click(
    screen.getByText("Click")
  );

  expect(mockFn).toHaveBeenCalled();
});

Example 5 — Mocking an API Call

// api.js
export async function fetchUser() {
  const response = await fetch("/api/user");
  return response.json();
}

// UserProfile.jsx
import { useEffect, useState } from "react";
import { fetchUser } from "./api";

function UserProfile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetchUser().then(setUser);
  }, []);

  if (!user) return <p>Loading...</p>;

  return <h1>{user.name}</h1>;
}

export default UserProfile;

import { render, screen } from "@testing-library/react";
import { vi } from "vitest";

vi.mock("./api", () => ({
  fetchUser: vi.fn()
}));

import { fetchUser } from "./api";

test("renders user name from API", async () => {
  fetchUser.mockResolvedValue({
    name: "John"
  });

  render(<UserProfile />);

  expect(
    await screen.findByText("John")
  ).toBeInTheDocument();
});

Example 6 — Testing Loading State

test("shows loading initially", () => {
  render(<UserProfile />);

  expect(
    screen.getByText("Loading...")
  ).toBeInTheDocument();
});

Example 7 — Using afterEach and cleanup

import { cleanup } from "@testing-library/react";
import { afterEach } from "vitest";

afterEach(() => {
  cleanup();
  vi.clearAllMocks();
});

Example 8 — Using userEvent

import userEvent from "@testing-library/user-event";

test("user types into input", async () => {
  render(<input />);

  const input = screen.getByRole("textbox");

  await userEvent.type(
    input,
    "hello"
  );

  expect(input).toHaveValue("hello");
});

Example 9 — Waiting for Async Updates

import { waitFor } from "@testing-library/react";

test("waits for element to appear", async () => {
  render(<UserProfile />);

  await waitFor(() =>
    expect(
      screen.getByText("John")
    ).toBeInTheDocument()
  );
});

Example 10 — Testing Forms

Forms are one of the most important real-world testing scenarios because they involve user input, validation, and submission logic.

// LoginForm.jsx
import { useState } from "react";

function LoginForm({ onSubmit }) {
  const [email, setEmail] = useState("");
  const [error, setError] = useState("");

  function handleSubmit(e) {
    e.preventDefault();

    if (!email) {
      setError("Email is required");
      return;
    }

    setError("");
    onSubmit(email);
  }

  return (
    <form onSubmit={handleSubmit}>
      <label htmlFor="email">
        Email
      </label>

      <input
        id="email"
        type="email"
        value={email}
        onChange={(e) =>
          setEmail(e.target.value)
        }
      />

      {error && (
        <p role="alert">
          {error}
        </p>
      )}

      <button type="submit">
        Submit
      </button>
    </form>
  );
}

export default LoginForm;

Test — Input Change

test("updates input value when user types", async () => {
  render(<LoginForm onSubmit={() => {}} />);

  const input = screen.getByLabelText(
    /email/i
  );

  await userEvent.type(
    input,
    "test@example.com"
  );

  expect(input).toHaveValue(
    "test@example.com"
  );
});

Test — Validation Error

test("shows error when form is submitted without email", async () => {
  render(<LoginForm onSubmit={() => {}} />);

  await userEvent.click(
    screen.getByRole("button", {
      name: /submit/i
    })
  );

  expect(
    screen.getByRole("alert")
  ).toHaveTextContent(
    "Email is required"
  );
});

Test — Successful Submission

import { vi } from "vitest";

test("calls onSubmit with email", async () => {
  const mockSubmit = vi.fn();

  render(
    <LoginForm
      onSubmit={mockSubmit}
    />
  );

  const input = screen.getByLabelText(
    /email/i
  );

  await userEvent.type(
    input,
    "user@test.com"
  );

  await userEvent.click(
    screen.getByRole("button", {
      name: /submit/i
    })
  );

  expect(mockSubmit).toHaveBeenCalledWith(
    "user@test.com"
  );
});

What These Examples Now Cover

This combined section now includes the core scenarios developers actually encounter:

Rendering components
User interaction
Lifecycle hooks
Function calls
Mocking APIs
Loading states
Async updates
Cleanup
Test isolation
Form validation
Form submission
User input handling

Best Practices for Testing React Components

Following best practices ensures tests remain reliable and maintainable.

Test Behavior, Not Implementation

Good:

expect(screen.getByText("Login")).toBeInTheDocument();

Avoid:

expect(component.state.isLoggedIn).toBe(true);

Keep Tests Independent

Each test should:

Run independently
Not rely on other tests
Not share state

Keep Tests Small
One test should verify one behavior.

Write Clear Test Names

Bad:

test("works", () => {})

Good:

test("shows error message when login fails", () => {})

Test Coverage in React with Vitest

Test coverage measures how much of your component code is executed during testing.

It helps identify untested logic.

Run Coverage

npm run test:coverage

Example Coverage Output
File % Stmts % Branch % Funcs % Lines
Counter 100 100 100 100

Coverage Folder

coverage/
  lcov-report/
    index.html

Open:

coverage/lcov-report/index.html

to view a visual report.

Important Note

High coverage does not mean high-quality tests.

Coverage shows:
What was executed.
Not whether behavior was correctly verified.

Conclusion

Unit testing in React is a natural extension of unit testing in JavaScript. The principles remain the same — isolate behavior, verify outcomes, and build confidence in your code.

Tools like Vitest make it easier to test components quickly and reliably, while React Testing Library encourages testing from a user's perspective.

As applications grow, testing becomes less about preventing bugs and more about enabling safe changes. Good tests allow developers to refactor, add features, and deploy with confidence.

Write tests not just to validate code — but to support the long-term health of your application.

Unit Testing in JavaScript: A Practical Guide with Jest

Alok Kumar — Mon, 23 Mar 2026 20:19:33 +0000

Think of Unit Testing as a software development technique where you break your software up into small, isolated units and write automated tests that ensure each unit works as expected.

In simpler terms, unit testing is about verifying that the smallest pieces of your application — usually functions — behave correctly under different conditions.

A unit can be:

A function
A method
A component
A utility
A hook
A service

The key idea is isolation.
You test one unit at a time, without depending on other parts of the system.

For example, instead of testing an entire application flow, you test a single function like:

function calculateTotal(price, quantity) {
  return price * quantity;
}

Why Unit Testing is Required?

Unit testing is not just a best practice — it is a core part of professional software development, especially as applications grow in size and complexity.

Without tests, every change introduces risk.
With tests, you gain confidence.

Here are the real reasons why unit testing is required -

1) To Catch Bugs Early

Finding bugs early is significantly cheaper and easier than fixing them later in production.

Unit tests act as an automated safety net that quickly detects issues when code changes.

Instead of discovering a bug:

During manual testing
In production
From a customer

You discover it immediately after running tests.

2) To Enable Safe Refactoring

As developers, we constantly refactor code to:

Improve readability
Optimize performance
Reduce duplication
Add new features

Without tests, refactoring is risky.

You don't know if something broke.

With tests, you can confidently modify code because the tests verify that behavior remains correct.

3) To Prevent Regression Bugs

A regression bug happens when a new change breaks existing functionality.

Unit tests prevent this.

Every time you run tests, you verify that previously working features still work.

This is critical in large applications where multiple developers are making changes simultaneously.

4) To Support Continuous Integration and Deployment (CI/CD)

Modern development workflows rely on automated testing.

Before code is deployed:

Tests run automatically
Failures block deployment
Only stable code is released

Code That Feels Simple at the Start Doesn't Stay Simple

What begins as a small function or a quick feature often grows as new requirements are introduced. Edge cases appear, validations are added, and business logic evolves. Over time, multiple developers may contribute to the same code, increasing its complexity.

A function that once handled a single scenario may eventually need to support:

Input validation
Error handling
Business rules
Performance optimizations
Backward compatibility

As complexity increases, the risk of introducing bugs also increases.
This is one of the key reasons unit testing becomes essential — it ensures that as code evolves, existing functionality continues to work as expected.

Unit Test Using Pure JavaScript

Before using testing frameworks like Jest or Vitest, it's important to understand that unit testing is simply verifying behavior, and this can be done using plain JavaScript.

Let's take a simple example -

function calculateTotal(price, quantity) {
  return price * quantity;
}

function runTests() {
  const tests = [
    { price: 100, quantity: 2, expected: 200 },
    { price: 50, quantity: 3, expected: 150 },
    { price: 0, quantity: 5, expected: 0 }
  ];

  tests.forEach((test, index) => {
    const result = calculateTotal(test.price, test.quantity);

    if (result === test.expected) {
      console.log(`✅ Test ${index + 1} Passed`);
    } else {
      console.log(`❌ Test ${index + 1} Failed`);
      console.log("Expected:", test.expected);
      console.log("Received:", result);
    }
  });
}

runTests();

What This Demonstrates

This is still a unit test, even though no library is used.

Because:

We executed a function
We compared the result with an expected value
We reported whether the behavior was correct

Testing frameworks like Jest simply automate and organize this process, but the core idea remains the same.

Unit Test Using Jest

Jest is a popular JavaScript testing framework used to write and run unit tests in a structured and automated way. It provides built-in features such as test runners, assertions, mocking, and reporting, making it easier to verify that individual units of code behave as expected.

Instead of manually checking results using if statements and console.log, Jest allows developers to define tests using readable functions like test() and validate outcomes using assertions like expect().

In simple terms, Jest standardizes and automates the unit testing process.

Example: Unit Test Using Jest

Function Under Test

function calculateTotal(price, quantity) {
  return price * quantity;
}

module.exports = calculateTotal;

Jest Test

const calculateTotal = require("./calculateTotal");

describe("calculateTotal", () => {
  test("returns correct total for valid inputs", () => {
    const result = calculateTotal(100, 2);
    expect(result).toBe(200);
  });

  test("returns correct total when price is zero", () => {
    const result = calculateTotal(0, 5);
    expect(result).toBe(0);
  });

  test("returns correct total for another valid case", () => {
    const result = calculateTotal(50, 3);
    expect(result).toBe(150);
  });
});

Unit testing with Jest follows a simple pattern:

Arrange → Act → Assert

Arrange — Set up input values
Act — Call the function
Assert — Verify the result

What we did:

// 1) Importing the Function to Test
const calculateTotal = require("./calculateTotal");

// 2) Using describe() to Group Tests
describe("calculateTotal", () => {

// 3) Writing Individual Test Cases with test()
test("returns correct total for valid inputs", () => {

// 4) Executing the Function (Act Step)
const result = calculateTotal(100, 2);

// 5) Verifying the Result with expect()
expect(result).toBe(200);

How to Run Jest

Running Jest involves installing the package, writing tests, and executing them using a command. Once configured, Jest automatically discovers and runs all test files in your project.

Step 1: Install Jest

First, install Jest as a development dependency.

npm install --save-dev jest

Step 2: Add a Test Script

Update the scripts section in your package.json file.

{
  "scripts": {
    "test": "jest"
  }
}

Step 3: Create a Test File

Jest automatically looks for files with names like:

*.test.js
*.spec.js

Example -

// calculateTotal.test.js

const calculateTotal = require("./calculateTotal");

test("calculates total correctly", () => {
  expect(calculateTotal(100, 2)).toBe(200);
});

Step 4: Run Jest

Now execute the test runner using:

npm test

Jest will:

Find all test files
Run the tests
Display results

Example output:

PASS  calculateTotal.test.js
✓ calculates total correctly (2 ms)

Mocking Network Calls in Jest

In real-world applications, functions often depend on external services such as APIs, databases, or third-party systems. These dependencies can make tests slow, unreliable, or difficult to control.

Mocking solves this problem.

Mocking is the process of replacing real dependencies with controlled, simulated versions during testing. Instead of making an actual network request, we provide a fake response and verify how our code behaves.

This ensures that unit tests remain:

Fast
Predictable
Independent
Isolated from external systems

Example:

// priceService.js

async function fetchPrice() {
  const response = await fetch("https://api.example.com/price");
  const data = await response.json();
  return data.price;
}

async function calculateTotal(quantity) {
  const price = await fetchPrice();
  return price * quantity;
}

module.exports = {
  fetchPrice,
  calculateTotal
};

Jest Test with the Mock:

const { calculateTotal, fetchPrice } = require("./priceService");

jest.mock("./priceService", () => ({
  fetchPrice: jest.fn()
}));

describe("calculateTotal", () => {
  test("returns correct total using mocked price", async () => {
    // Arrange
    fetchPrice.mockResolvedValue(100);

    // Act
    const result = await calculateTotal(2);

    // Assert
    expect(fetchPrice).toHaveBeenCalled();
    expect(result).toBe(200);
  });
});

What it does:

// 1) jest.mock() Replaces the Real Function
jest.mock("./priceService", () => ({
  fetchPrice: jest.fn()
}));

// 2) mockResolvedValue() Controls the Response
fetchPrice.mockResolvedValue(100);

// above simulates:
return Promise.resolve(100);

// 3) Testing Behavior, Not the Network
expect(fetchPrice).toHaveBeenCalled();
expect(result).toBe(200);

Test Driven Development (TDD)

Test Driven Development (TDD) is a software development approach where tests are written before the actual implementation code. Instead of writing functionality first and testing later, developers define the expected behavior through tests and then write code to satisfy those tests.

The primary goal of TDD is to ensure correctness, improve design, and maintain confidence in the codebase as it evolves.

At the heart of TDD lies a simple, repeatable cycle known as:

Red → Green → Refactor

The Red, Green, Refactor Cycle

TDD follows a disciplined three-step workflow that guides development in small, incremental steps.

1) Red — Write a Failing Test 🔴

The first step in TDD is to write a test that defines the desired behavior of a feature or function. Since the functionality has not been implemented yet, the test will fail.

This failure is intentional and confirms that the test is valid and capable of detecting missing or incorrect behavior.

Example:

test("calculates total price correctly", () => {
  expect(calculateTotal(100, 2)).toBe(200);
});

At this stage:

The function may not exist yet
The implementation is incomplete
The test fails

This is the Red phase.

2) Green — Write the Minimum Code to Pass the Test 🟢

Next, we implement just enough code to make the test pass.
The focus here is correctness, not optimization or perfection.

Example:

function calculateTotal(price, quantity) {
  return price * quantity;
}

Once the implementation satisfies the test, the test runner shows a successful result.

This is the Green phase.

3) Refactor — Improve the Code Safely 🔵

After the test passes, we improve the code while ensuring that behavior remains unchanged. This step focuses on code quality, readability, and maintainability.

function calculateTotal(price, quantity) {
  if (price < 0 || quantity < 0) {
    throw new Error("Invalid input");
  }

  return price * quantity;
}

Because tests already exist, we can refactor confidently.
If something breaks, the tests will immediately detect it.

This is the Refactor phase.

Test Coverage

Test coverage is a metric that measures how much of your application's code is executed when your tests run. It helps developers understand which parts of the codebase are tested and which parts are not.

In simple terms, test coverage answers the question:

"How much of my code is actually being tested?"

Test coverage does not guarantee that your code is bug-free, but it provides visibility into the areas that may need additional testing.

Why Test Coverage Matters

Test coverage helps teams maintain confidence in their codebase, especially as applications grow in size and complexity.

It is useful because it:

Identifies untested code
Reduces the risk of hidden bugs
Improves code reliability
Supports safe refactoring
Provides measurable testing goals

For example, if a critical function is never executed during testing, test coverage will highlight it immediately.

How to Run Test Coverage in Jest

Jest provides built-in support for generating coverage reports.

Run Coverage

npm test -- --coverage

Example Coverage Output

File	% Stmts	% Branch	% Funcs	% Lines
calculateTotal	100	100	100	100

Where Coverage Reports Are Stored

After running coverage, Jest creates a folder:

coverage/

Inside it, you will find:

coverage/
  └── lcov-report/
        └── index.html

Final Note on Unit Testing in JavaScript

Unit testing is not just about writing tests — it's about building confidence in your code.

As applications grow, code changes frequently. New features are added, bugs are fixed, and logic evolves. Without tests, every change introduces uncertainty. With unit tests in place, developers gain a reliable safety net that ensures existing functionality continues to work as expected.

Unit testing also encourages better design. It pushes developers to write smaller, more focused functions, reduce unnecessary dependencies, and think clearly about expected behavior.

In the long run, unit testing saves time, reduces bugs, and improves code quality.

Write tests not because you have to — write tests because future you (and your team) will depend on them.

Quick Sort in Javascript

Alok Kumar — Tue, 13 Jan 2026 09:13:40 +0000

Quick Sort is one of the most important and widely used sorting algorithms.

It’s fast, elegant, and a favorite in interviews — if you understand it properly.

This post explains Quick Sort from basics to advanced, covering:

Simple (functional) Quick Sort
In-place Quick Sort
Lomuto partition scheme
Hoare partition scheme
Pros & Cons
Time and space complexity

What is Quick Sort?

Quick Sort is a divide-and-conquer algorithm.

The idea is simple:

Pick a pivot element
Partition the array so:
- elements smaller than pivot go left
- elements larger than pivot go right
Recursively apply the same logic to left and right sub-arrays

“Quick Sort is quick because it reduces the problem size drastically at every step.”

Simple (Functional) Quick Sort

Let’s start with the most intuitive version.

const quickSort = (arr) => {
  if (arr.length <= 1) {
    return arr;
  }

  let pivot = arr[0];
  let left = [];
  let right = [];

  for (let i = 1; i < arr.length; i++) {
    if (arr[i] < pivot) {
      left.push(arr[i]);
    } else {
      right.push(arr[i]);
    }
  }

  return [...quickSort(left), pivot, ...quickSort(right)];
};

How this works

Base case: arrays of size 0 or 1 are already sorted
Pivot chosen as the first element
Remaining elements are split into left and right
Recursively sort both halves
Combine results

Pros

Very easy to read and explain
Great for learning and interviews

Cons

❌ Not in-place
❌ Uses extra memory
❌ Worst-case O(n²) when pivot choice is bad

In-place Quick Sort

In-place Quick Sort:

Does not create extra arrays
Uses indexes and swaps
Much more space-efficient
Preferred in real systems and interviews

The key to in-place Quick Sort is the partitioning step.

Lomuto Partition Scheme

Idea

Pivot = last element
i keeps track of the “smaller than pivot” region
j scans the array

Code

const lomutoPartition = (arr, low, high) => {
  let pivot = arr[high];
  let i = low - 1;

  for (let j = low; j < high; j++) {
    if (arr[j] < pivot) {
      i++;
      [arr[i], arr[j]] = [arr[j], arr[i]];
    }
  }

  [arr[i + 1], arr[high]] = [arr[high], arr[i + 1]];
  return i + 1;
};

What happens here

Before:
[34, 56, 3, 234, 6, 7]   pivot = 7

After partition:
[3, 6 | 7 | 56, 234, 34]

The pivot (7) is now in its final sorted position.

Quick Sort using Lomuto

const quickSort = (arr, low = 0, high = arr.length - 1) => {
  if (low < high) {
    const pivot = lomutoPartition(arr, low, high);
    quickSort(arr, low, pivot - 1);
    quickSort(arr, pivot + 1, high);
  }
  return arr;
};

let arr = [34, 56, 3, 234, 6, 7];
quickSort(arr);

Lomuto — Pros & Cons

Pros

Simple and easy to implement
Pivot ends in correct sorted position
Excellent for interviews

Cons

More swaps
Performs poorly with many duplicates
Slightly slower than Hoare

Hoare Partition Scheme

Idea

Pivot = first element
Two pointers:
- i moves from left
- j moves from right
Swap elements on the wrong side

Code

const hoarePartition = (arr, low, high) => {
  let pivot = arr[low];
  let i = low - 1;
  let j = high + 1;

  while (true) {
    do {
      i++;
    } while (arr[i] < pivot);

    do {
      j--;
    } while (arr[j] > pivot);

    if (i >= j) return j;

    [arr[i], arr[j]] = [arr[j], arr[i]];
  }
};

What happens here

Before:
[34, 56, 3, 234, 6, 7]   pivot = 34

After partition:
[ 7, 6, 3 | 234, 56, 34 ]

Then it returns the partition index = 2.

Quick Sort using Hoare

const quickSortHoare = (arr, low = 0, high = arr.length - 1) => {
  if (low < high) {
    const p = hoarePartition(arr, low, high);
    quickSortHoare(arr, low, p);
    quickSortHoare(arr, p + 1, high);
  }
  return arr;
};

Lomuto vs Hoare

Lomuto:

Pivot goes to its final sorted position
Everything left < pivot, everything right > pivot
Returns pivot index

Hoare:

Pivot does NOT move to final position
It only splits the array into two valid halves
Returns a partition index, not pivot index
Fewer swaps → faster

Hoare says:
“I don’t care where pivot ends up — I only ensure left side ≤ pivot and right side ≥ pivot.”

Why recursive calls look different from Lomuto ?


// lomuto 
quickSort(arr, low, pivotIndex - 1);
quickSort(arr, pivotIndex + 1, high);
// hoare

quickSort(arr, low, partitionIndex);
quickSort(arr, partitionIndex + 1, high);

Because:

Lomuto returns pivot index
Hoare returns boundary index

Summary:

Feature	Lomuto	Hoare
Simplicity	⭐⭐⭐⭐	⭐⭐
Swaps	More	Fewer
Speed	Slower	Faster
Pivot placement	Exact index	Not guaranteed
Duplicate handling	Poor	Better

Time and Space Complexity

Time Complexity

Case	Complexity
Best	O(n log n)
Average	O(n log n)
Worst	O(n²)

Worst case occurs when pivot selection is poor (already sorted array).

Space Complexity

Functional Quick Sort → O(n)
In-place Quick Sort → O(log n) (recursion stack)

Insertion Sort in JavaScript

Alok Kumar — Tue, 09 Dec 2025 04:56:23 +0000

Insertion Sort is an intuitive, stable, in-place sorting algorithm that builds the final sorted array one item at a time. It’s efficient on small or nearly-sorted arrays and is a common interview staple. This post shows the canonical shift implementation, the descending version, a detailed dry run, and complexity notes.

What Insertion Sort does (plain English)

Treat the left portion of the array as sorted (initially the first element).
Take the next element (the key) and insert it into the correct position within the sorted portion by shifting larger elements to the right.
Repeat until the entire array is sorted.

Think of sorting playing cards in your hand: take the next card and slide it into the right spot.

Canonical (shift-based) Insertion Sort — JavaScript

const insertion = (arr) => {
  for (let i = 1; i < arr.length; i++) {
    let key = arr[i];
    let j = i - 1;

    // shift elements of arr[0..i-1] that are greater than key
    while (j >= 0 && arr[j] > key) {
      arr[j + 1] = arr[j];
      j--;
    }

    // place key after the element just smaller than it
    arr[j + 1] = key;
  }

  return arr;
};

console.log(insertion([12, 45, 2, 1, 54, 3]));
// => [1, 2, 3, 12, 45, 54]

Step-by-step Dry Run

Array:

[12, 45, 2, 1, 54, 3]

i = 1 (key = 45)

j = 0 → arr[0] (12) > 45? No → insert 45 at index 1
Array: [12, 45, 2, 1, 54, 3]

i = 2 (key = 2)

j = 1 → 45 > 2 → shift 45 right → [12, 45, 45, 1, 54, 3], j = 0
j = 0 → 12 > 2 → shift 12 right → [12, 12, 45, 1, 54, 3], j = -1
place key at j+1 = 0 → [2, 12, 45, 1, 54, 3]

i = 3 (key = 1)

shift 45, 12, 2 right → place 1 at index 0
Array: [1, 2, 12, 45, 54, 3]

i = 4 (key = 54)

45 > 54? No → place 54 at index 4 (no shifts)
Array: [1, 2, 12, 45, 54, 3]

i = 5 (key = 3)

shift 54, 45, 12 right → place 3 at index 2
Final: [1, 2, 3, 12, 45, 54]

Descending Order

To sort descending, flip the comparison (> → <) in the while condition:

const insertionDesc = (arr) => {
  for (let i = 1; i < arr.length; i++) {
    let key = arr[i];
    let j = i - 1;
    while (j >= 0 && arr[j] < key) {
      arr[j + 1] = arr[j];
      j--;
    }
    arr[j + 1] = key;
  }
  return arr;
};

console.log(insertionDesc([12, 45, 2, 1, 54, 3]));
// => [54, 45, 12, 3, 2, 1]

Complexity & Characteristics (Quick Summary)

Time Complexity
- Best: O(n) — when array is already sorted (shift-based; only comparisons)
- Average: O(n²)
- Worst: O(n²) — reverse-sorted input
Space Complexity: O(1) — in-place
Stability: Stable (shift-based sorting preserves equal-element order)
When to use: small arrays, nearly-sorted data, or when stability matters
Why it’s useful in practice: often used as the base case sorter for hybrid algorithms (Timsort, introsort variants) on small subarrays

Bubble Sort in JavaScript — Step-by-Step Guide

Alok Kumar — Thu, 04 Dec 2025 04:38:02 +0000

Bubble Sort is one of the simplest sorting algorithms to understand.

It repeatedly compares adjacent elements and swaps them if they’re in the wrong order — just like bubbles rising to the top of water, the largest elements “bubble up” to the end of the array.

In this post, we’ll walk through:

How Bubble Sort works
A JavaScript implementation
A step-by-step dry run
An optimized version (early exit)
Time & space complexity
ES6 destructuring swap explanation

What is Bubble Sort?

Bubble Sort works by repeatedly traversing the array and swapping adjacent elements if they are out of order.

After each full pass, the largest element among the unsorted section ends up at its correct final position.

This continues until the array is sorted.

JavaScript Implementation (Ascending Order)

const bubble = (arr) => {
  let n = arr.length;

  for (let i = n - 1; i >= 0; i--) {
    for (let j = 0; j < i; j++) {
      if (arr[j] > arr[j + 1]) {
        // ES6 destructuring swap
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
      }
    }
  }

  return arr;
};

console.log(bubble([12, 45, 2, 1, 54, 3]));
// => [1, 2, 3, 12, 45, 54]

Step-by-Step Dry Run

Given the array:

[12, 45, 2, 1, 54, 3]

Pass 1

Compare and swap adjacent pairs:

12 45 → OK  
45 2 → swap  
45 1 → swap  
45 54 → OK  
54 3 → swap

After Pass 1:

[12, 2, 1, 45, 3, 54]

Pass 2

12 2 → swap  
12 1 → swap  
12 45 → OK  
45 3 → swap

After Pass 2:

[2, 1, 12, 3, 45, 54]

This continues until the array becomes:

[1, 2, 3, 12, 45, 54]

Optimized Bubble Sort (Early Exit)

One major inefficiency of basic Bubble Sort is that it continues looping even when the array is already sorted.

We can fix that using a swapped flag:

const bubbleOptimized = (arr) => {
  let n = arr.length;

  for (let i = n - 1; i >= 0; i--) {
    let swapped = false;

    for (let j = 0; j < i; j++) {
      if (arr[j] > arr[j + 1]) {
        [arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];
        swapped = true;
      }
    }

    if (!swapped) break; // No swaps = already sorted
  }

  return arr;
};

With this optimization:

Best-case time becomes O(n)
Average and worst cases remain O(n²)

Time & Space Complexity (Summary)

Scenario	Complexity
Best Case (already sorted)	O(n) with optimization, O(n²) without
Average Case	O(n²)
Worst Case	O(n²)
Space Complexity	O(1) — in-place
Stable?	Yes — Bubble Sort is stable by default

Understanding the ES6 Swap

Throughout this post, we used:

[arr[j], arr[j + 1]] = [arr[j + 1], arr[j]];

This works because:

The right-hand side is evaluated first, producing something like [1, 12]
Then JavaScript assigns values left-to-right:

arr[j] = 1
arr[j + 1] = 12

It’s the same as writing:

let temp = arr[j];
arr[j] = arr[j + 1];
arr[j + 1] = temp;

But cleaner.

Final Thoughts

Bubble Sort is not the most efficient algorithm, but it is:

Easy to understand
Great for learning swapping & comparisons
Stable
Good for demonstrating algorithmic thinking

If you're practicing for interviews or learning sorting fundamentals, mastering Bubble Sort is a solid first step.

Selection Sort in JavaScript — A Clean, Simple Guide

Alok Kumar — Tue, 02 Dec 2025 08:26:12 +0000

Selection Sort is one of the simplest sorting algorithms. It may not be the fastest, but it's extremely useful for learning how sorting logic works under the hood. In this blog, we'll walk through Selection Sort step-by-step, implement it in JavaScript, sort in descending order, and finally understand how the ES6 destructuring swap works.

Why learn Selection Sort?

It helps you understand algorithmic thinking.
It’s commonly asked in interviews.
It teaches core concepts like finding minimum/maximum, nested loops, and swapping.

What is Selection Sort?

Selection Sort divides the array into two parts:

Sorted part (starts empty)
Unsorted part (the entire array initially)

At each step:

Find the minimum element in the unsorted part.
Swap it with the first element of the unsorted section.
Expand the sorted section by one.

Think of it like selecting the smallest card from a deck and placing it at the beginning, again and again.

Step-by-Step Example

Given this array:

[11, 43, 2, 12, 6, 3, 7]

Iteration 1:

Minimum is 2 → swap with 11

[2, 43, 11, 12, 6, 3, 7]

Iteration 2:

Next minimum is 3 → swap with 43

[2, 3, 11, 12, 6, 43, 7]

Iteration 3:

Next minimum is 6 → swap with 11

[2, 3, 6, 12, 11, 43, 7]

…and so on until the array becomes fully sorted.

JavaScript Implementation (Ascending Order)

const selection = (arr) => {
  for (let i = 0; i < arr.length; i++) {
    let minIndex = i;

    for (let j = i + 1; j < arr.length; j++) {
      if (arr[j] < arr[minIndex]) {
        minIndex = j;
      }
    }

    // ES6 destructuring swap
    [arr[i], arr[minIndex]] = [arr[minIndex], arr[i]];
  }

  return arr;
};

console.log(selection([11,43,2,12,6,3,7]));

Sorting in Descending Order

To make Selection Sort descend instead of ascend:

Find the maximum instead of minimum.
Change < to > in the comparison.

const selectionDesc = (arr) => {
  for (let i = 0; i < arr.length; i++) {
    let maxIndex = i;

    for (let j = i + 1; j < arr.length; j++) {
      if (arr[j] > arr[maxIndex]) {
        maxIndex = j;
      }
    }

    [arr[i], arr[maxIndex]] = [arr[maxIndex], arr[i]];
  }

  return arr;
};

console.log(selectionDesc([11,43,2,12,6,3,7]));

Understanding the ES6 Destructuring Swap

If you've seen this line:

[arr[i], arr[minIndex]] = [arr[minIndex], arr[i]];

You might wonder: How does this magically swap values without a temporary variable?

This is a concise way to swap two elements without an explicit temporary variable. Here’s why it’s safe:

Right-hand side is evaluated first. If arr[i] is 11 and arr[minIndex] is 2, the RHS becomes the temporary array [2, 11].
The engine then assigns values left-to-right:

arr[i] = 2
arr[minIndex] = 11

Even though arr[i] is overwritten during the operation, the original values were already captured in the RHS, so nothing is lost.

Equivalent traditional swap:

let tmp = arr[i];
arr[i] = arr[minIndex];
arr[minIndex] = tmp;

Why use destructuring?

Shorter and more readable
Avoids naming a temp variable
Modern idiom commonly used in JS codebases and interviews

Summary

Selection Sort is simple but not very efficient compared to modern sorting algorithms. Here's a quick breakdown of its performance:

Time Complexity

Best Case: O(n²)
Average Case: O(n²)
Worst Case: O(n²)

Reason:
Regardless of whether the array is sorted or not, Selection Sort always scans the remaining elements to find the minimum or maximum.

Space Complexity

O(1) — It sorts the array in-place without using extra memory (other than a few variables).

Stability

Not stable by default. A stable sort preserves the relative order of equal elements; Selection Sort does not guarantee that because it swaps elements far apart.

When to Use It

When simplicity matters more than performance.
When working with very small arrays.
When teaching or learning how sorting works under the hood.

Not Ideal For

Large datasets — better choices like Merge Sort, Quick Sort, or TimSort (used by modern JS engines) are much faster.

A Developer’s Guide to Getting Started With Cursor

Alok Kumar — Wed, 19 Nov 2025 21:01:54 +0000

Software development is changing fast, and AI-powered tools are becoming a natural part of the workflow. One tool getting a lot of attention is Cursor—an AI-first code editor designed to boost productivity without replacing your ability to think and code.

This article breaks down what Cursor actually is, common fears around adopting it, how to use it properly, new vs experienced developers, some downsides, etc.

What Is Cursor?

Cursor is a code editor built around AI assistance. Think of it like VS Code, but with an intelligent companion sitting inside the editor. This companion can read your codebase, make changes, generate new files, refactor existing ones, and help you understand complex areas.

You can write prompts directly inside your editor, select parts of your code, and ask Cursor to fix, rewrite, generate, or explain things. The key idea is:
you stay in control, while Cursor accelerates the work.

Transition from ChatGPT to Cursor

Many developers start by using ChatGPT for coding help. It works well for learning, brainstorming, or writing small snippets. But once you begin working on full projects, pure chat-based coding hits limits.

Here’s how the transition usually happens:

1. ChatGPT helps, but can’t “see” your project

You paste pieces of your code into ChatGPT, but it doesn’t understand the full context.
Cursor solves this by reading your entire codebase. It knows the file structure, imports, dependencies, and project flow.

2. You move from “copy–paste coding” to “live coding”

With ChatGPT, you copy code into the chat and paste its output back into your editor.
Cursor removes that friction.
You select code → ask for changes → get a diff → apply instantly.

3. You stop explaining everything manually

ChatGPT forgets context after a few messages. Cursor keeps the project indexed and remembers the overall structure.

4. You can run Agents on your actual files

Something ChatGPT cannot do:
“Update all components to use the new API and adjust imports.”

Cursor can do multi-file changes safely with your supervision.

5. You shift from “chat-based assistance” to “project-based assistance”

Cursor feels less like chatting and more like collaborating with a teammate inside the editor.

In short:
ChatGPT is great for answers.
Cursor is great for actual coding.

Agents vs. Editor: What’s the Difference?

Cursor is not just “ChatGPT inside VS Code.” It also supports Agents, which behave differently from simple AI prompts.

Editor Mode

When you're using AI inside the editor:

You choose the code.
You choose the prompt.
Cursor shows a diff before applying anything.
You review, accept, or reject changes.

It’s still your workflow, just enhanced.

Agent Mode

Agents act like automated workers inside your project.
They can:

Scan your entire codebase
Understand structure and files
Make multiple edits
Create new files
Solve issues step-by-step

You give them a high-level instruction like:
“Add Google login to this project and update routing accordingly.”

Agents handle the steps, while you supervise.

In short:
The editor helps you do things.
Agents help you get things done.

The Fear: “Will Cursor Harm My Coding Skills?”

This fear is common. Many developers worry that depending on AI will:

reduce problem-solving ability
break their thinking flow
make them rely too much on generated code

But the truth is similar to calculators:
Tools don’t make you weaker unless you stop thinking.

Cursor still expects you to:

understand what you’re building
review every change
guide the AI
maintain architecture and logic

AI can't replace real engineering judgment. It only speeds up repetitive or mechanical work.

If anything, Cursor frees your mind from boilerplate so you can focus on design, structure, and real creativity.

How to Use Cursor Properly (With Examples)

The tool becomes powerful when used correctly. Here’s how.

1. Ask Cursor to explain existing code

Useful when exploring unknown repos.

Explain what this function does and point out any potential bugs.

2. Refactor small pieces of code

Be specific with requests.

Refactor this function to make it more readable without changing behavior.

3. Use diff review

Never accept changes blindly.

4. Let Cursor generate boilerplate

APIs, models, components, configs—it’s great at this.

Create a basic Express.js REST API with JWT authentication.

5. Use Agents for larger tasks

Such as:

adding new modules
updating folder structures
cleaning unused code
adding tests across the project

Find all class components and convert them to functional components using hooks.

How Freshers vs Experienced Developers Use Cursor (and Why Freshers Often Struggle)

When developers first switch to Cursor, freshers and experienced engineers use it very differently.
This gap creates two very different outcomes:

Freshers often feel overwhelmed, confused, or frustrated.
Experienced developers feel like they just unlocked a superpower.

Here’s why this difference happens.

Why Freshers Struggle With Cursor

Freshers usually fall into a few common traps:

1. They give very vague prompts
They write things like:
“Fix my code” or “Make this work.”

Cursor doesn’t know what the user actually wants, so the output becomes random or wrong.
This frustrates them and makes them think Cursor “doesn’t work.”

2. They rely fully on AI instead of understanding
They ask Cursor to write everything, then they don’t understand the generated code.
When something breaks, they panic because they never built mental ownership.

3. They ask Cursor to build entire features in one go
Freshers think:
“If AI is powerful, I’ll just tell it to build the whole thing.”

But big tasks require planning, clear steps, and context—things freshers skip.

4. They accept every diff without reading
This leads to bugs they don’t understand and lose trust in the tool.

Why Experienced Developers Find Cursor Easy

Experienced devs get better results because they:

1. Give clear, scoped prompts
They don’t ask for the world.
They ask for a small, well-defined change.

2. Break tasks into steps
They might ask Cursor to analyse first, then modify, then clean up.

3. Understand the code first
So they can judge whether Cursor’s output makes sense.

4. Review diffs like code reviews
They accept only the parts that make sense.

Cursor becomes a helper, not a replacement.

Same Task, Two Prompt Styles

(How a Fresher Writes vs How an Experienced Dev Writes)

Let’s take a simple task:

“Add JWT auth to an Express API.”

How a Fresher Usually Writes the Prompt

Add JWT auth to my project.

This fails because:

Cursor doesn’t know the routes
doesn’t know the user model
doesn’t know the login flow
doesn’t know where to plug in middleware

Result:
Half-broken code and frustration.

How an Experienced Dev Writes the Prompt

You have full access to the project. 
I want to add JWT auth in small steps.

Step 1: Create a helper file for generating and verifying tokens.
Use jsonwebtoken. Do not modify any routes yet.
Once done, show me the diff.

Then they continue:

Next step: Add a login route in routes/auth.js. 
Use the user model from models/user.js. 
Return the JWT token on successful login.

Then:

Final step: Add a verifyToken middleware and apply it only to the /profile route.
Show me a diff before applying.

Result:
Stable, readable, safe changes.

Some Limitations of Using Cursor

Cursor is powerful, but it has limitations.

1. Sometimes overconfident
It may propose changes that break something subtle.

2. Needs clear instructions
Vague prompts lead to vague results.

3. Risk of becoming passive
If you accept everything blindly, you stop learning.

4. Can struggle with huge legacy repos
Indexing or navigation may feel slow.

5. Occasional hallucinations
It might assume a file or function exists when it doesn’t.

Conclusion

Cursor isn’t a replacement for developers. It is a productivity enhancer that helps you code faster, understand projects better, and avoid repetitive tasks.

The best part is that Cursor works with your existing workflow instead of replacing it. The shift from ChatGPT to Cursor reflects the natural evolution of AI-assisted coding—from chatting about code to collaborating inside the codebase itself.

As AI becomes more integrated into development, tools like Cursor will play a bigger role in how software gets built. Exploring it now puts you ahead of the curve.

TypeScript Fundamentals

Alok Kumar — Mon, 23 Jun 2025 07:04:31 +0000

Welcome to this concise and practical guide to TypeScript Fundamentals. Whether you're transitioning from JavaScript or enhancing your React+TypeScript workflow, this article is structured to serve as a quick-reference cheatsheet.

Each section focuses on core TypeScript topics, explained with beginner-friendly yet production-relevant examples.

Variables and Values

Variable Declaration & Type Inference

TypeScript can infer the type based on the value assigned, which reduces redundancy but still offers safety.

let name = "Alice"; // inferred as string
let age: number = 25; // explicitly typed

Using inference helps keep your code clean without losing type safety.

`any` & Type Casting

any disables type checking. Use it cautiously. Type casting helps inform TypeScript of the actual type when it can't infer correctly.

let data: any = "hello";
let len = (data as string).length;

Avoid overusing any — it defeats TypeScript’s purpose.

Functions and Return Types

Explicit return types prevent unexpected behaviors and help with readability.

function greet(user: string): string {
  return `Hello, ${user}`;
}

Even if return types are inferred, it's good practice to specify them.

Objects, Arrays, and Tuples

Objects and Property Types

You can define the exact shape of an object using inline types or interfaces.

const user: { name: string; age: number } = {
  name: "Alice",
  age: 30,
};

Index Signatures

When object keys are dynamic, use index signatures.

interface UserMap {
  [key: string]: string;
}

const users: UserMap = {
  user1: "Alice",
  user2: "Bob",
};

Array Types

Arrays can be typed using type[] or Array<type>.

let scores: number[] = [90, 85, 100];
let names: Array<string> = ["Alice", "Bob"];

Tuples and `readonly`

Tuples are fixed-length arrays with specific types for each element.

let pair: readonly [string, number] = ["id", 1];

Use readonly to make tuples immutable.

Structural vs Nominal Typing

TypeScript is structurally typed. If two types have the same structure, they are considered compatible.

interface A { x: number }
interface B { x: number }

let a: A = { x: 1 };
let b: B = a; // valid

Union and Intersection Types

Union types allow multiple possible types, while intersection types combine types.

// Union
type Status = "loading" | "success" | "error";

// Intersection
type Person = { name: string } & { age: number };

Union is like "either or", Intersection is like "both at once".

Interfaces and Type Aliases

Type Alias

A type alias gives a name to any type, useful for primitives, unions, or intersections.

type ID = number | string;

Interface `extends` and `implements`

Interfaces can extend other interfaces or be implemented by classes.

interface Base {
  id: number;
}

interface User extends Base {
  name: string;
}

class Customer implements User {
  id = 1;
  name = "John";
}

Open Interfaces

Interfaces are open-ended and can be merged automatically, useful for extending types across modules.

interface Profile {
  name: string;
}

interface Profile {
  age: number;
}

// Merged: { name: string, age: number }

Recursive Types

Recursive types can describe deeply nested structures like JSON trees or folders.

type NestedList = string | NestedList[];

Type Queries, Callables, and Constructables

`typeof`, `keyof`, `in`

These operators allow you to build types from values and objects.

const user = { name: "Alice", age: 30 };
type User = typeof user; // { name: string; age: number }
type Keys = keyof User; // "name" | "age"

Type Registry Pattern

Build a type-safe object structure from static data.

const registry = {
  user: { name: "Alice" },
  product: { title: "Book" },
};

type Registry = typeof registry;
type RegistryKeys = keyof Registry;

Callables

Functions can also be typed using interfaces.

interface Greet {
  (name: string): string;
}

const greet: Greet = (name) => `Hi, ${name}`;

`void` Type

Functions that don't return anything use void.

function log(message: string): void {
  console.log(message);
}

Constructables & Function Overloads

You can type constructors and function overloads.

class Animal {
  constructor(public name: string) {}
}

interface Constructor {
  new (name: string): Animal;
}

`this` Types

You can explicitly define what this refers to in a function.

function say(this: { name: string }) {
  console.log(this.name);
}

Useful when using .call() or binding to custom objects.

Explicit Function Return Types

Encouraged for readability and better auto-completion.

const add = (a: number, b: number): number => a + b;

Classes and Type Guards

Class Fields and Methods

TypeScript brings full support for class features with types.

class User {
  constructor(public name: string, private age: number) {}
}

Access Modifiers

public, private, and protected control visibility.

class Employee {
  private salary: number;
  constructor(public name: string, salary: number) {
    this.salary = salary;
  }
}

Parameter Properties & Overrides

Shorthand for initializing fields directly from constructor parameters.

class Admin extends User {
  constructor(name: string, age: number, public role: string) {
    super(name, age);
  }
}

Type Guards

Custom checks to narrow types at runtime.

function isString(val: any): val is string {
  return typeof val === "string";
}

Great for refining types in conditional logic.

Generics

Basic Generics

Generics let you create reusable, type-safe components and functions.

function identity<T>(arg: T): T {
  return arg;
}

Generic Props in React

Create components that work with any data type.

interface ListProps<T> {
  items: T[];
  renderItem: (item: T) => JSX.Element;
}

function List<T>({ items, renderItem }: ListProps<T>) {
  return <>{items.map(renderItem)}</>;
}

Wrapping Up

Congrats on covering the TypeScript fundamentals! From variable inference to generics and type guards, you now have the base needed to:

Work confidently with React + TypeScript
Understand type safety across your codebase
Scale apps with maintainable interfaces and classes

What's Next?

Dive into React with TypeScript Patterns
Learn TypeScript with Redux / RTK Query
Explore Advanced Utility Types (Partial, Pick, Omit, Record)
Use TypeScript with APIs and form validation libraries like Zod/Yup

Introduction to Backend Architectures (Part 2)

Alok Kumar — Sun, 22 Jun 2025 13:04:40 +0000

In Part 1, we explored the fundamental principles behind backend architecture: what it is, when it matters, and how to approach its design and implementation. Now in Part 2, let’s break down the three most commonly used backend architecture patterns and understand their strengths, weaknesses, and ideal use cases.

The three we'll cover:

Monolithic Architecture
Distributed Architecture (Service-Oriented & Microservices)
Serverless Architecture

🔹 1. Monolithic Architecture

A Monolithic Architecture is a traditional model where all components—UI, business logic, and data access—are packaged into a single deployable unit. It’s often the go-to structure for early-stage applications due to its simplicity.

✅ Pros

Simplicity: Development, testing, and deployment are straightforward since everything is contained in one codebase.
Consistency: All modules share the same libraries and runtime.
Efficiency: Internal method calls are faster than network requests.

❌ Cons

Limited Scalability: You can’t scale individual components; the whole system must scale together.
Rigid Deployments: Any change, even a minor one, often requires redeploying the entire application.
Growing Complexity: As the app grows, code becomes harder to manage and onboard new devs becomes slower.

🛠️ Use Cases

MVPs and small-scale applications
Applications with stable, well-defined domains
High-performance systems where low-latency communication is crucial (e.g., trading engines)

🔹 2. Distributed Architectures (Service-Oriented)

Distributed architectures break applications into smaller services, each responsible for a specific business capability. This category includes generic service-based architectures and microservices.

2.1 Generic Services

Generic services are independent modules that provide specific capabilities. They may run within the same app or as separate services in a distributed setup.

Example: An authentication service used by multiple products.
Often used in legacy systems or as a transition stage from monoliths to microservices.

2.2 Microservices Architecture

A Microservices Architecture is a refined form of service-oriented design where each service:

Is independently deployable
Runs in its own process
Communicates via HTTP/REST, gRPC, or message queues (like RabbitMQ or Kafka)

The core principle? Autonomy and isolation, enabling scalability, agility, and resilience.

✅ Pros

Independent Development & Deployment: Teams can ship updates to their own services independently.
Fault Isolation: A failing service won’t bring down the whole system.
Polyglot Freedom: Each service can be built using the best-fit language or tech stack.

❌ Cons

Operational Complexity: Requires monitoring, service discovery, and distributed logging.
Data Management: Ensuring consistency across services is challenging (eventual consistency, distributed transactions).
Harder Testing: End-to-end and integration testing becomes more complicated.

🛠️ Use Cases

E-commerce platforms with modular domains (catalog, cart, payment)
Streaming platforms (recommendations, playback, user profiles)
Scalable social networks and multiplayer games

🔹 3. Serverless Architecture

Serverless Architecture abstracts away infrastructure management entirely. Applications run in ephemeral containers managed by cloud platforms—typically via Function-as-a-Service (FaaS).

You write the code, define when it should run (trigger), and the provider handles:

Provisioning
Scaling
Availability

✅ Pros

No server management: Focus solely on business logic.
Auto-scaling: Effortless scaling based on workload.
Pay-as-you-go: You’re billed only for execution time and resources used.

❌ Cons

Cold Start Latency: Especially in low-traffic scenarios, startup time may affect performance.
Debugging & Testing Challenges: Difficult to emulate and troubleshoot locally.
Cost Creep: For long-running tasks or high-traffic systems, costs can become unpredictable.

🛠️ Use Cases

Real-time file processing (e.g., image resizing on upload to S3 via AWS Lambda)
Real-time analytics (e.g., stream processing using AWS Kinesis + Lambda)
Data pipelines (ETL jobs)
Static websites and JAMstack apps (e.g., deployed via Netlify or Cloudflare Pages)

🧠 Choosing the Right Architecture

Feature	Monolithic	Microservices	Serverless
Simplicity	✅ Easy to start	❌ Complex setup	✅ Easiest infra
Scalability	❌ Limited	✅ Per-service	✅ Auto-scaled
Maintenance	❌ Tough when large	✅ Isolated services	✅ No infra to manage
Deployment	❌ All-at-once	✅ Service-wise	✅ Trigger-based
Cost Efficiency	✅ for small apps	✅ at scale	✅ for sporadic tasks

📚 Final Thoughts

Understanding backend architecture patterns is essential for making informed technical decisions. Each architecture has its trade-offs, and the "best" choice depends on your team size, budget, scalability needs, and application complexity.

In summary:

Monoliths are great to start with—simple and efficient.
Microservices shine at scale—modular and robust.
Serverless is the future for many—agile and cost-efficient.

Use this guide to weigh your options carefully and architect with confidence.

Inspired by Erik Reinert’s Backend Architecture course on Frontend Masters.

Introduction to Backend Architectures (Part 1)

Alok Kumar — Mon, 16 Dec 2024 19:27:10 +0000

Backend architecture is a fundamental concept in software development, dictating how servers, databases, and application logic come together to create a functional and scalable system. This article is the first part of a two-part series designed to introduce you to the essentials of backend architectures and their practical implementation.

In Part 1, we will cover the following:

What are Backend Architecture Designs?: Understanding the core idea and its importance.
When to Use Backend Architecture Designs?: Identifying the right scenarios and use cases.
How to Implement Backend Architecture Designs?: Practical steps to get started.

In Part 2, we will explore common backend architecture patterns, such as monolithic, microservices, and serverless architectures, providing deeper insights into their pros, cons, and when to use them.

These articles draw inspiration from Erik Reinert's insightful course on Frontend Masters, a valuable resource for developers seeking to build robust and scalable applications.

So let's dive in.

What are Backend Architecture Designs?

Backend architecture refers to the structural design and organization of the components that power the backend of an application. It includes how data is stored, processed, and served to users, often involving databases, servers, APIs, and application logic. A well-thought-out backend architecture ensures that the system is efficient, scalable, and maintainable, acting as the backbone of modern software systems.

Importance of Backend Architecture Design

Facilitates Communication:
Backend architecture provides a clear blueprint of the system, enabling team members to communicate effectively. Developers, architects, and stakeholders can use this common reference to discuss design, resolve issues, and align their efforts. For example, a modular architecture allows teams to divide responsibilities, ensuring everyone understands how their part integrates into the whole.
Improves Efficiency and Productivity:
Efficient backend designs eliminate redundancy by promoting code reuse and standardizing processes. For instance, using a centralized API for all clients (web, mobile) reduces duplication of effort. This productivity gain helps teams deliver high-quality software faster, especially in agile development cycles.
Ensures Alignment with Goals:
Backend architecture acts as a foundation for aligning technical solutions with business objectives. By defining clear data flows and robust logic, the architecture ensures that user needs, such as fast response times or secure transactions, are met while adhering to organizational goals like scalability or cost-effectiveness.

Key Principles of Backend Architecture

Modularity:
Breaking the system into smaller, self-contained modules or services makes the codebase easier to manage, test, and scale. For example, in an e-commerce application, separating the payment, inventory, and user management modules can simplify development and troubleshooting.
Scalability:
A good backend architecture ensures the system can handle growing workloads, such as increased user traffic or data volume. Horizontal scaling (adding more servers) and vertical scaling (upgrading existing hardware) are common strategies enabled by thoughtful architecture.
Robustness:
Robust systems are designed to handle errors gracefully and recover quickly from failures. Techniques like load balancing, redundancy, and failover mechanisms ensure high availability and resilience, even under adverse conditions.
Flexibility:
As business requirements evolve, backend systems should adapt without major overhauls. Flexible architectures allow for easy integration of new features, migration to new technologies, or adjustments in workflows without disrupting the system.

Key Challenges in Backend Architecture

Complexity:
Striking the right balance between a powerful yet comprehensible design is critical. Overly complex architectures can lead to technical debt, slow development cycles, and difficulty in onboarding new team members. Simplicity without compromising functionality is key.
Adaptability:
Business needs can change rapidly, requiring the backend to evolve. Whether it’s adding support for new payment methods or accommodating a sudden increase in traffic, adaptable systems can respond quickly without requiring significant downtime.
Security:
Protecting sensitive data, such as user information or transaction details, is non-negotiable. Strong encryption, authentication protocols, and regular security audits are necessary to safeguard against breaches and vulnerabilities.
Technology Selection:
Choosing the right stack for the system is crucial. For instance, relational databases like PostgreSQL may be ideal for structured data, whereas NoSQL databases like MongoDB work better for unstructured or rapidly changing data. Selecting frameworks, cloud providers, and tools that align with the project’s requirements impacts performance and long-term maintainability.
Resource Allocation:
Backend architectures often rely on external resources like cloud infrastructure, databases, and engineering time. Proper planning ensures optimal utilization without overspending. Cloud services like AWS or Azure offer scalability but require careful management to avoid unnecessary costs.
Stakeholder Alignment:
Getting buy-in from all stakeholders—developers, project managers, and business leaders—is essential. Conflicting priorities or unclear goals can derail the project, making it critical to establish shared understanding and expectations from the outset.

Backend architecture is not just a technical blueprint but a strategic tool to align the system with user needs, business goals, and future scalability. By adhering to best practices and addressing challenges proactively, developers can build robust and adaptable systems that stand the test of time.

When Should You Use Backend Architecture Designs?

A well-structured backend architecture is not always necessary, but knowing when to implement it can save significant time and effort down the line. Let’s explore the scenarios where adopting backend architecture design is beneficial.

Ideal Scenarios for Using Backend Architecture

Starting a New Project:
Implementing backend architecture at the start provides a structured approach from day one. It ensures clear workflows, scalability, and maintainability while preventing technical debt.
Scaling an Existing System:
When scaling a system to accommodate more users or handle higher data loads, well-planned architecture identifies bottlenecks and areas for optimization, such as improving database queries or optimizing API response times.
Managing Complex Problems:
For projects with intricate workflows or diverse functionalities, backend architecture helps break the system into manageable, modular parts. This division simplifies debugging, testing, and future updates.
Improving Efficiency and Productivity:
Backend architecture streamlines processes, promotes code reuse, and reduces redundancy. It provides clear guidelines, allowing teams to work cohesively and deliver faster.

Factors to Consider Before Implementing Backend Architecture

Project Requirements:
Analyze the specific needs of your project, including functionality, performance, security, and scalability. A small MVP may require less complex architecture compared to a global e-commerce platform.
Team Expertise:
The skills and experience of your team can influence your choice of architecture. For example, a team experienced in microservices may prefer distributed systems over a monolithic approach.
Budget:
Architectural choices have cost implications. Advanced systems like serverless architectures may incur higher cloud expenses, so align the architecture with your financial constraints.
Time Constraints:
Projects with tight deadlines might benefit from simpler architectures that prioritize speed over extensive scalability features.
Project Size and Complexity:
Larger, more complex projects demand robust architectural solutions, while smaller projects may not justify the overhead of detailed backend designs.
Ease of Maintenance:
Consider how easy it will be to maintain and update the system. A modular design is often easier to manage in the long term than tightly coupled systems.

Strategic Considerations When Choosing Backend Architecture

Technological Choices:
Stay informed about the latest trends in technology. For example, the rise of serverless computing or edge functions may influence your choice.
User Feedback:
Understanding user needs and pain points can guide architecture decisions. For example, if users demand faster loading times, optimizing backend workflows and caching becomes a priority.
Market Trends:
Industry trends can provide insights into what competitors are adopting, helping you make informed choices about scalability or technology stacks.
Legal and Regulatory Requirements:
Ensure that your architecture complies with regulations like GDPR, HIPAA, or CCPA, especially when handling sensitive data.

By assessing these factors and considerations, you can determine whether implementing a robust backend architecture design is the right step for your project.

How to Implement Backend Architecture Design

Implementing backend architecture involves a series of well-planned steps to ensure that the system is functional, scalable, and maintainable. Below is a structured approach to implementing a robust backend architecture.

1. Choose the Appropriate Design

The first step is selecting the architecture that best fits your project’s needs. Evaluate the following:

Project Requirements: Understand the functionality, scalability, and performance goals of the application.
Team Expertise: Ensure the team has the skills required for the chosen architecture.
Available Resources: Factor in budget, infrastructure, and development time.
Future Scalability: Choose a design that can grow with your application, such as microservices for high-traffic apps.

2. Define the Architecture (Document It!)

Creating detailed documentation of the architecture is essential for clarity and alignment among stakeholders. This step includes:

System Overview: Provide a high-level description of the system, including its purpose and key components.
Component Diagrams: Visualize the architecture through diagrams, showing how different components interact.
Technology Stack: Specify the technologies, frameworks, and tools to be used.
APIs and Data Flow: Define the APIs and describe how data will move across the system.
Security Measures: Outline strategies for authentication, authorization, and data protection.

3. Develop the Architecture

With the design finalized, start building the system:

Set Up Infrastructure: Provision servers, databases, and cloud resources as needed.
Implement Modules: Develop individual components or services according to the modular design.
Integrate Components: Ensure seamless communication between components using APIs, message brokers, or other integration methods.
Follow Best Practices: Write clean, maintainable, and well-documented code adhering to industry standards.

4. Test the Architecture

Testing is crucial to validate that the architecture meets the desired requirements:

Unit Testing: Verify that individual components or modules work as expected.
Integration Testing: Ensure that combined components interact correctly.
Load Testing: Simulate high traffic to identify performance bottlenecks.
Security Testing: Check for vulnerabilities and ensure compliance with security protocols.
User Acceptance Testing (UAT): Gather feedback from stakeholders or end-users to confirm the system meets their needs.

5. Deploy the Architecture

Once testing is complete, deploy the system for production use:

Environment Setup: Configure staging and production environments.
CI/CD Pipelines: Automate build, test, and deployment processes for efficiency and reliability.
Monitor Deployment: Use tools to monitor performance, uptime, and errors post-deployment.

6. Maintain the Architecture

Maintenance ensures that the system remains reliable and adaptable over time:

Monitor Performance: Continuously track system metrics and resolve issues promptly.
Apply Updates: Regularly update dependencies, frameworks, and libraries to stay secure and efficient.
Optimize Components: Identify areas for improvement and refactor code or infrastructure as needed.
Handle Feedback: Act on user and stakeholder feedback to introduce new features or address concerns.
Plan for Scalability: Ensure that the architecture can adapt to future growth in users or functionality.

By following these steps, you can implement a backend architecture that is not only functional but also scalable, secure, and aligned with your project goals.

DEV Community: Alok Kumar

Part 1 — What Actually Happens When Code Runs

From JavaScript to the CPU

What does the CPU actually do?

The CPU doesn't get everything from RAM

Cache hits, misses and locality

Latency vs Bandwidth

What about numbers?

CPU-bound vs I/O-bound

Putting it all together

Computer Fundamentals: No BS

Why I'm writing this

The path I'm taking

1. What Actually Happens When Code Runs

2. Operating Systems

3. Networking: From fetch() to Packets

4. Databases + Storage

5. Concurrency + Node.js Internals

6. Distributed Systems Fundamentals

7. Put Everything Together

Unit Testing in React Using Vitest — A Practical Guide

What is Unit Testing in React?

How Unit Testing in React Fits Next to Unit Testing in JavaScript

Unit Testing in JavaScript

Unit Testing in React

The Relationship

Vitest

Why Vitest ?

Setting Up Vitest in a React Project

What to Test in React

Core React Testing Examples

Example Component — Counter

Best Practices for Testing React Components

Test Coverage in React with Vitest

Conclusion

Unit Testing in JavaScript: A Practical Guide with Jest

Why Unit Testing is Required?

Code That Feels Simple at the Start Doesn't Stay Simple

Unit Test Using Pure JavaScript

Unit Test Using Jest

How to Run Jest

Mocking Network Calls in Jest

Test Driven Development (TDD)

The Red, Green, Refactor Cycle

Test Coverage

Final Note on Unit Testing in JavaScript

Quick Sort in Javascript

What is Quick Sort?

Simple (Functional) Quick Sort

In-place Quick Sort

Lomuto Partition Scheme

Quick Sort using Lomuto

Hoare Partition Scheme

Quick Sort using Hoare

Lomuto vs Hoare

Time and Space Complexity

Insertion Sort in JavaScript

What Insertion Sort does (plain English)

Canonical (shift-based) Insertion Sort — JavaScript

Step-by-step Dry Run

Descending Order

Complexity & Characteristics (Quick Summary)

Bubble Sort in JavaScript — Step-by-Step Guide

What is Bubble Sort?

JavaScript Implementation (Ascending Order)

Step-by-Step Dry Run

Optimized Bubble Sort (Early Exit)

Time & Space Complexity (Summary)

Understanding the ES6 Swap

Final Thoughts

Selection Sort in JavaScript — A Clean, Simple Guide

Why learn Selection Sort?

What is Selection Sort?

Step-by-Step Example

JavaScript Implementation (Ascending Order)

Sorting in Descending Order

Understanding the ES6 Destructuring Swap

Equivalent traditional swap:

Why use destructuring?

Summary

3. Networking: From `fetch()` to Packets

`any` & Type Casting

Tuples and `readonly`

Interface `extends` and `implements`

`typeof`, `keyof`, `in`

`void` Type

`this` Types