DEV Community: Cheryl Mataitini

Integration Testing In .NET Using Docker Testcontainers

Cheryl Mataitini — Sat, 19 Jul 2025 00:00:59 +0000

Overview

This article covers how to use Docker for integration testing in an ASP.NET Core Web API project. We'll use the Testcontainers library to spin up SQL Server containers for our integration tests.

We'll see how to set up an integration test class that uses a database container and resets its state between tests.

Tooling

xUnit
Docker
TestContainers.MsSql NuGet package (other packages support containers for PostgreSQL, Redis, RabbitMQ, and other dependencies)
EF Core and migrations

Integration Test Setup

We're testing a demo ASP.NET Core Web API project called BlindDate, and we want to run our integration tests against a real database. To do this, we use a test project BlindDate.Tests, which includes:

BlindDate.Tests/
└── IntegrationTests/
    ├── BaseIntegrationTest.cs
    ├── BlindDateControllerTests.cs
    ├── IntegrationTestWebAppFactory.cs
    └── SqlServerContainerFixture.cs

Here's how the pieces fit together:

SqlServerContainerFixture.cs

Responsible for starting a disposable SQL Server container using Testcontainers.
Implements IAsyncLifetime to manage container lifecycle.

ing Testcontainers.MsSql;

namespace BlindDate.Tests.IntegrationTests
{
    /// <summary>
    /// SQL Server container fixture.
    /// Provides an isolated, disposable SQL Server instance for integration testing.
    /// </summary>
    public class SqlServerContainerFixture : IAsyncLifetime
    {
        private const string SqlPassword = "P@ssword123!";
        private const string SqlImage = "mcr.microsoft.com/mssql/server:2022-latest";

        public MsSqlContainer Container { get; }

        public SqlServerContainerFixture()
        {
            Container = new MsSqlBuilder()
                .WithImage(SqlImage)
                .WithPassword(SqlPassword)
                .WithCleanUp(true) // Ensures Docker cleans up the container after tests
                .WithPortBinding(1433, assignRandomHostPort: true) // Allows multiple containers to run in parallel without port collisions.
                .Build();
        }

        public async Task InitializeAsync() => await Container.StartAsync();

        public async Task DisposeAsync() => await Container.DisposeAsync();
    }
}

IntegrationTestWebAppFactory.cs

A custom WebApplicationFactory class that boots our application in-memory.

Overrides service configuration to inject the SQL Server connection string.
Contains logic to reset the database using EF Core (EnsureDeleted + Migrate).

using Microsoft.AspNetCore.Hosting;
using Microsoft.AspNetCore.Mvc.Testing;
using Microsoft.AspNetCore.TestHost;
using Microsoft.EntityFrameworkCore;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.DependencyInjection.Extensions;

namespace BlindDate.Tests.IntegrationTests
{
    /// <summary>
    /// WebApplicationFactory for integration testing.
    /// Overrides the real application's service configuration to use a test database.
    /// </summary>
    internal class IntegrationTestWebAppFactory : WebApplicationFactory<Program>
    {
        private readonly string _connString;

        public IntegrationTestWebAppFactory(string connString)
        {
            _connString = connString;
        }

        protected override void ConfigureWebHost(IWebHostBuilder builder)
        {
            builder.ConfigureTestServices(services =>
            {
                services.RemoveAll(typeof(DbContextOptions<BlindDateDbContext>));

                services.AddSqlServer<BlindDateDbContext>($"{_connString};Database=BlindDateTestDb;");
            });
        }

        public async Task ResetDatabaseAsync()
        {
            using var scope = Services.CreateScope();
            var db = scope.ServiceProvider.GetRequiredService<BlindDateDbContext>();
            await db.Database.EnsureDeletedAsync();
            await db.Database.MigrateAsync();
        }
    }
}

BaseIntegrationTests.cs

Contains shared test setup logic for tests.
Implements IClassFixture<SqlServerContainerFixture> and IAsyncLifetime.
Instantiates IntegrationTestWebAppFactory using the SQL Server container’s connection string.
Automatically resets the database before each test via IAsyncLifetime
Exposes a HttpClient for calling the in-memory API.

namespace BlindDate.Tests.IntegrationTests
{
    public class BaseIntegrationTest : IClassFixture<SqlServerContainerFixture>, IAsyncLifetime
    {
        protected readonly HttpClient _httpClient;
        internal readonly IntegrationTestWebAppFactory _app;
        private readonly SqlServerContainerFixture _fixture;

        protected BaseIntegrationTest(SqlServerContainerFixture fixture)
        {
            _fixture = fixture;
            _app = new IntegrationTestWebAppFactory(_fixture.Container.GetConnectionString());
            _httpClient = _app.CreateClient();
        }

        public async Task InitializeAsync() => await _app.ResetDatabaseAsync();
        public Task DisposeAsync() => Task.CompletedTask;
    }
}

Test Class

Inherits from BaseIntegrationTest to reuse test setup logic.

using BlindDate.Api.Contracts;
using BlindDate.Api.Entities;
using FluentAssertions;
using System.Net.Http.Json;

namespace BlindDate.Tests.IntegrationTests
{
    public class BlindDateControllerTests : BaseIntegrationTest
    {
        public BlindDateControllerTests(SqlServerContainerFixture fixture) : base(fixture) { }

        [Fact]
        public async Task JoinBlindDateRequest_AddsPersonToMatch()
        {
            // Arrange
            JoinBlindDateRequest request = new("Jane");

            // Act
            var response = await _httpClient.PostAsJsonAsync("/api/blindDate", request);

            // Assert
            response.EnsureSuccessStatusCode();
            var matchResponse = await response.Content.ReadFromJsonAsync<BlindDateMatchResponse>();
            matchResponse?.Id.Should().BePositive();
            matchResponse?.Person1.Should().Contain("Jane");
            matchResponse?.State.Should().Be(nameof(BlindDateMatchState.WaitingForDate));
        }

        [Fact]
        public async Task JoinBlindDateRequest_JoinsOpenMatchAsSecondPerson()
...

This setup gives you fast, reliable, and isolated integration tests that work against real infrastructure - without the overhead of managing shared test environments.

How Docker Works: Architecture, Concepts, and Practical Insights

Cheryl Mataitini — Sun, 24 Nov 2024 02:27:06 +0000

Docker is a containerization tool that uses lightweight virtualization to create isolated environments called containers. Unlike virtual machines (VMs) which emulate entire operating systems, Docker containers share the host's kernel, making them faster and more efficient.

What We’ll Cover

An exploration of Docker’s core concepts, including images, containers, and networking.
Insights into how Docker works under the hood, such as namespaces, cgroups, and the Docker architecture.
Practical examples to reinforce key concepts, like running containers and inspecting images.

Why Docker Matters
Core Concepts: Images, Containers and more
Docker Architecture and Components
How Docker Works Under the Hood
Networking in Docker
Persistent Storage
Challenges and Limitations

Why Docker Matters

Docker plays a big role in modern IT:

Consistency: Ensures applications run the same across all environments.
Efficiency: Containers are lightweight and use fewer resources compared to VMs.
Portability: Easily moves applications between different environments; local setups, on-premises servers and cloud platforms.
Scalability: Simplifies dynamic scaling, particularly for microservices architectures.
Automation: Streamlines development and CI/CD workflows.

Core Concepts

IMAGES
Docker images are the blueprint for containers, the image has everything that an application needs to run - code, dependencies and configurations. Here’s how images work:

Built from Dockerfiles

A Dockerfile is a script with instructions to build an image.
Each instruction (e.g., FROM, RUN, COPY) creates a new layer.
Example:

FROM ubuntu:latest
RUN apt-get update && apt-get install -y curl

What this Dockerfile does:
- FROM ubuntu:latestspecifies the base for the Docker image. It uses the latest version of Ubuntu as the starting point for the build.
- The RUN apt-get update && apt-get install -y curl uses standard Linux/Unix commands to install the curl utility for making HTTP requests. The y flag confirms installation to avoid getting interactive prompts.
- Each command creates a new layer in the image and using && combines them into a single layer for efficiency.

Layered Filesystem

Each layer represents a change (e.g., installing software or adding files)
Layers are cached and reused for faster builds and efficient storage.

Example: Pulling and inspecting an image:

docker pull ubuntu
docker inspect ubuntu

CONTAINERS
Containers are lightweight, isolated environments created from the images.

How Containers Work

Containers are running instances of images.
They include a writable layer for temporary changes, separate from the image’s readonly layers.

Key Features

Isolation: Containers run independently. They don’t interfere with other things.
Portable: Containers run the same across different environments.
Ephemeral: Changes in a container are lost when the container is removed unless its explicitly saved.

Example: Run a container from the Ubuntu image we pulled:
We can view the docker images we have pulled locally with docker image ls:

Run the below command to start a container using the ubuntu image, and opens a bash terminal session inside. Try running commands like ls, cat /etc/os-release. Running exit will exit the terminal session.

docker run -it ubuntu bash

REGISTRY
A Docker registry is a storage and distribution system for Docker images.
The most popular public registry is Docker Hub.

How Docker Registries Work

When you pull an image (e.g., docker pull ubuntu), Docker fetches it from a registry.
Registries host and organize images, often using repositories and tags (e.g., ubuntu:latest).

Docker Architecture

CLIENT-SERVER MODEL
Docker uses a client-server model to manage containers.

Docker Client: The client is the part of Docker responsible for interacting with the Docker Daemon. It includes the Docker CLI, which is the command-line interface used to run commands like docker run or docker build.
Docker Daemon: A background process (dockerd) that handles tasks like building, running and managing containers.
Communication happens over a REST API, enabling flexibility (e.g., remote management).

Run docker version to display client and server versions.

DOCKER ENGINE COMPONENTS
The Docker Engine consists of key components:

Image Builder: Constructs Docker images using instructions in a Dockerfile.
Container Runtime: Runs and manages containers, handling isolation and resource allocation.
Orchestration Layer: Coordinates multi-container setups (e.g. Docker Swarm or integrates with tools like Kubernetes).

How Docker Works Under the Hood

NAMESPACES

Isolates processes, networks, and file systems.
Example: Inside a container, ps aux shows only processes running inside the container, not the host system. This demonstrates how namespaces isolate the container’s process view.

CONTROL GROUPS (cgroups)

Limit and allocate resources like CPU and memory, and disk I/O for each container.
Example: Use docker stats to view resource usage.

UNION FILE SYSTEMS

Allow image layers to stack into a single, unified filesystem.
Changes during container runtime are saved in the top writable layer, preserving the original image.
Example: Run docker history <image> to see the image’s layers and how they stack.

Networking in Docker

Docker provides different networking options to connect to containers and external systems:

BRIDGE (default)
- Creates an isolated network for containers on the same host.
- Containers can communicate with each other via internal IPs but require port mapping to be accessed externally.
HOST
- Removes network isolation and directly uses the host’s network stack.
- Useful for performance-critical applications but sacrifices isolation.
OVERLAY
- Enables communication between containers running on different hosts in a Docker Swarm or Kubernetes cluster.

Example: Run a container with a mapped port:

docker run -p 8080:80 nginx and test it in a browser.

This maps port 8080 on your host to port 80 in the container (where Nginx serves HTTP requests).
Open a browser and navigate to http://localhost:8080 to verify Nginx is running. You’ll see the default Nginx welcome page.

This shows how port mapping allows external access to the containerized application running in Docker’s default bridge network.

Inspecting and Creating Networks

Use docker network ls to list available networks and docker network inspect <network> for detailed information.
Create custom networks with docker network create <network_name> to better control container communication.

Persistent Storage

VOLUMES vs. BIND MOUNTS
Purpose: Both provide ways to store data that persists beyond the lifecycle of a container.

DIFFERENCES

Volumes:
- Managed by Docker.
- Stored in Docker's directory (e.g., /var/lib/docker/volumes/).
- Recommended for portability and easier management.
Bind Mounts:
- Use a specific directory on the host system
- Offers more control but required manual management.
- Good for sharing directories or files from the host system with the container

Example: Create a volume and running a container with persistent data:

Create a volume:

docker volume create mydata

Run a container and map the volume:

docker run --name ubuntu1 -v mydata:/data -it ubuntu bash

Now from the terminal inside the container, write some data to /data:

echo "Hello!" > /data/hello.txt
exit

Start a new container with the same volume to verify persistence:

docker run --name ubuntu2 -v mydata:/data -it ubuntu bash
cat /data/hello.txt

This shows how data written to /data in container ubuntu1 persisted even when that container was removed. We ran the ubuntu2 container with the same volume to verify persistence.

Challenges and Limitations

Shared kernel issues

Containers on the same host share the host’s kernel.
A vulnerability in the kernel can compromise all containers, making security isolation less robust that virtual machines.

Resource overhead for large deployments

While lightweight individually, managing large numbers of containers can strain system resources like CPU, memory and networking.
Scaling requires planning and may necessitate orchestration tools like Kubernetes, which also introduces complexity.

Conclusion

Docker has transformed how we build, ship, test and run applications, making containerization a cornerstone of modern IT. By exploring its core concepts and understanding how it works under the hood, you’ll develop a skill that streamlines workflows and enables smarter, more efficient solutions.

Dockerizing SQL Server with Pre-Restored Databases

Cheryl Mataitini — Mon, 11 Nov 2024 19:17:17 +0000

Docker Containers

Docker is a tool for creating lightweight, portable containers that run services in isolated environments.

Creating a Customised SQL Server Docker Image

We’ll create a custom Docker image for SQL Server with a pre-restored database. Preloading the database in the image is useful when you need to run a container with the database for testing, automated testing in CI/CD pipelines, development environments, and any scenario where consistent data and easy database resets are needed.

Prerequisites

Docker Desktop installed
Basic familiarity with Docker and Dockerfiles
SQL Server familiarity

Overview – What We’ll Cover

Create a Database Backup File: Generate a backup file of the SQL Server database.
Write a Dockerfile: Define the Dockerfile to set up the SQL Server environment and configure the database.
Create a Database Restore Script: Add a script to restore the database from the backup file during the build.
Set Up Secrets for the Build: Securely pass the SA_PASSWORD using Docker BuildKit secrets.
Build the Docker Image: Build the Docker image with the pre-restored database.
Run a Container from the Image: Start a container using the custom Docker image with the preloaded database.

Create Database Backup File

We can create a backup file for this DemoDb database in Microsoft SQL Server Management Studio (SSMS).

To do this, right click on the database, select Tasks > Back Up, chose a file location for the backup, and select the ‘Full’ backup type. This process generates a .bak file, which can be used to restore the database in a Docker container.

Note: multiple databases can be preloaded onto a Docker image, but for this example we will just preload this DemoDb database.

Write a Dockerfile

FROM mcr.microsoft.com/mssql/server:2022-latest

# Accept license agreement
ENV ACCEPT_EULA=Y

USER root

# Copy files to container.
COPY DemoDb.bak /var/opt/mssql/DemoDb.bak
COPY pre-restore-db.sh /usr/src/app/pre-restore-db.sh

# Add executable permissions to script.
# Run database restore script with the password accessed as a secret.
# Remove backup files.
RUN --mount=type=secret,id=SA_PASSWORD \
  chmod +x /usr/src/app/pre-restore-db.sh \
  && SA_PASSWORD=$(cat /run/secrets/SA_PASSWORD) /bin/bash /usr/src/app/pre-restore-db.sh \
  && rm /usr/src/app/pre-restore-db.sh /var/opt/mssql/DemoDb.bak

# Ensure SQL Server is started when the container runs.
ENTRYPOINT ["/opt/mssql/bin/sqlservr"]

What this Dockerfile does:

Set up Base Image: Uses the latest SQL Server 2022 image from Microsoft’s container registry.
Environment Variables: Configures SQL Server to accept the license agreement (ACCEPT_EULA=Y).
Run Commands as Root: Switches to the root user to allow administrative tasks during the build.
Copy Files to Container: Copies the SQL backup file and database restore script into the container.
Set Permissions and Restore Database: Grants executable permissions to the restore script and restores the DemoDb database.
- Securely Access Password: Uses RUN --mount=type=secret,id=SA_PASSWORD to mount the SA_PASSWORD as a secret accessible only during the build step. When building the Docker image, we’ll pass the SA password using Docker BuildKit.
- Set SA_PASSWORD Variable: Reads the password securely with SA_PASSWORD=$(cat /run/secrets/SA_PASSWORD), making it available for the restore script without storing it in the final image.
- Clean Up: Removes the restore script and backup file after the database is restored to keep the image lean.
Define Entrypoint: Specifies SQL Server as the main process to start when the container runs.

Create a Database Restore Script

This script, pre-restore-db.sh, is run in the Dockerfile to restore the DemoDb database:

# Start SQL Server in the background
/opt/mssql/bin/sqlservr &

# Wait for SQL Server to come up
sleep 10s

# Restore DemoDb database
/opt/mssql-tools18/bin/sqlcmd -S localhost -U SA -P "$SA_PASSWORD" -C \
  -Q "RESTORE DATABASE DemoDb FROM DISK='/var/opt/mssql/DemoDb.bak' WITH MOVE 'DemoDb' TO '/var/opt/mssql/data/DemoDb.mdf', MOVE 'DemoDb_log' TO '/var/opt/mssql/data/DemoDb_log.ldf'" -C

# Stop SQL Server after the restoration is complete
kill $(pgrep sqlservr)

What this script does:

Starts SQL Server in the background: Runs the SQL Server instance so that the restore command can connect to it.
Waits for SQL Server to initialize: Pauses for a few seconds to ensure SQL Server is fully up and running..
Restores the DemoDb database: Uses the sqlcmd tool to restore the DemoDb database from a .bak file located in the container, with data and log files moved to the appropriate directories.
Stops SQL Server: After the restore process is complete, SQL Server is stopped to finalize the image build.

Setting Up Secrets for the Build

To securely pass the SA_PASSWORD for SQL Server without embedding it in the Dockerfile, we’ll use Docker BuildKit secrets. This method ensures the password is only accessible during the build process and is not stored in the final image layers.

Note: If security is not a primary concern for the password (e.g., it’s a temporary password only for building the Docker image), you could pass the password as an ARG in the Dockerfile.

Create a Secret File: Create a file named sa_password.txt with your SQL Server password.
Enable BuildKit from your terminal:
- For Unix-based environments (Linux, macOS) or Git Bash: Run export DOCKER_BUILDKIT=1
- For Windows PowerShell: Run $env:DOCKER_BUILDKIT = "1"

Build the Docker Image

Open a terminal in the directory containing the Dockerfile, along with the pre-restore-db.sh restore script, the database backup file, and the sa_password.txt file.

Run the following command to build the Docker image, passing the password from sa_password.txt securely:

docker build --secret id=SA_PASSWORD,src=sa_password.txt -t demodb-1.0 .

Replace the argument following ‘-t’ with your image tag. In this case we created the tag demodb-1.0.

We can see the image created with docker image ls:

Run a Container from the Image

Use the docker run command to run the container using the image we just created.
For Unix-based environments (Linux, macOS) or Git Bash:

docker run -e 'ACCEPT_EULA=Y' -e 'MSSQL_SA_PASSWORD=********' \
   --name 'demodb' -p 1401:1433 \
   -d demodb-1.0

For Windows PowerShell:

docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=********" `
   --name "demodb" -p 1401:1433 `
   -d demodb-1.0

What this command does:

Starts a container named 'demodb' with SQL Server accessible on port 1401 on your host machine.
The MSSQL_SA_PASSWORD is passed to set the SA password for SQL Server in the live container (replace the value with your password).

We can see the container running with docker ps:

We can now access the SQL Server running in the container from SSMS:
Start a connection to SQL Server:

Server name: localhost,1401
Authentication: SQL Server Authentication
Login Username: sa
Login Password: password you specified when running the container in the previous step

Once connected, we can see the restored database is there with all the data as expected.

How to Create Reusable Logic with Custom React Hooks

Cheryl Mataitini — Sun, 10 Nov 2024 01:29:37 +0000

What are React Hooks?

React’s built-in Hooks like useState and useEffect make it possible to manage state and lifecycle features directly in functional components. But when we need reusable logic across components, custom Hooks provide a way to keep our code organized and scalable.

Why are Hooks useful and when to use them

Hooks encapsulate reusable logic, making it easier to manage state and lifecycle features across components.

Custom Hooks are especially useful for handling forms, data fetching, and shared state, reducing redundancy and making our codebase scalable and maintainable.

What makes a function a ‘Hook’ in React?

A function is considered a Hook in React if it encapsulates reusable stateful logic and follows the naming convention by being prefixed with “use”.

The “use” prefix signals to React that it’s a Hook, allowing it to apply special internal rules (covered later) to manage the function’s behavior.

EXAMPLE

Source code available here on GitHub.

Our example app consists of forms that capture user information. It has two sections: ‘Personal Details’ and ‘Payment Details. Each section captures data and requires validation. Here’s how custom hooks simplify form handling and validation.

This is the structure of the app, we’ll be walking through these files specifically: PersonalDetailsForm.jsx for defining form fields, useForm.js custom Hook for managing state and submissions, and useValidation.js custom Hook for centralized validation logic.

PersonalDetailsForm.jsx – Using useForm and validation schema

This is the component file for the ‘Personal Details’ form.

import { Input, Dropdown, Button } from "@/components";
import useForm from "@/hooks/useForm";
import { validations } from "@/util/validationHelper";

const PersonalDetailsForm = ({ title }) => {
  const initialData = {
    FirstName: "",
    LastName: "",
    Email: "",
    ReceiveMarketing: false
  };

  // Validations
  const validationSchema = {
    FirstName: [
      {
        validator: validations.required,
        message: "First name is required"
      },
      {
        validator: (value) => validations.minLength(value, 2),
        message: "First name must be at least two characters"
      }
    ],
    LastName: [
      {
        validator: validations.required,
        message: "Last name is required"
      }
    ],
    Email: [
      {
        validator: validations.required,
        message: "Email is required"
      },
      { validator: validations.email, message: "Invalid email" }
    ]
  };

  // Custom Hook useForm for state management and validation handling
  const { formData, handleInputChange, handleSubmit, validationProps } =
    useForm(initialData, () => console.log(formData), validationSchema);

  return (
    <>
      <div className="bg-white rounded-md p-6">
        <form onSubmit={handleSubmit}>
          <h2 className="text-2xl font-semibold text-orange-600 pb-4">
            {title}
          </h2>
          <Input
            label="First Name"
            placeholder="John"
            name="FirstName"
            onChange={handleInputChange}
            value={formData.FirstName}
            {...validationProps("FirstName")}
          />
          <Input
            label="Last Name"
            placeholder="Doe"
            name="LastName"
            onChange={handleInputChange}
            value={formData.LastName}
            {...validationProps("LastName")}
          />
          <Input
            label="Email"
            placeholder="Email"
            name="Email"
            onChange={handleInputChange}
            value={formData.Email}
            {...validationProps("Email")}
          />

          <Dropdown
            label="Would you like to receive marketing emails from us?"
            name="ReceiveMarketing"
            onChange={handleInputChange}
            value={formData.ReceiveMarketing}
            items={[
              { label: "Yes", value: true },
              { label: "No", value: false }
            ]}
            isRequired={false}
            isValid={true}
          />

          <Button type="submit" text="Submit" />
        </form>
      </div>
    </>
  );
};

export default PersonalDetailsForm;

In PersonalDetailsForm.jsx, we initialize initialData to define field values and use validationSchema to specify validation rules. These are passed to the custom Hook useForm, which provides functions like handleInputChange for updating form state and validationProps for error handling and displaying error messages to the user.

useForm.js Custom Hook – Handling Form State and Submission

The custom useForm Hook manages form state with formData and handles submission. Form field changes are handled with handleInputChange. This function parses different data types (like text, checkboxes and numbers) and validates each field on change, keeping our PersonaDetailsForm component clean.

import { useState } from "react";
import useValidation from "@/hooks/useValidation";

const useForm = (initialValues, onSubmitCallback, validationSchema = {}) => {
  // Set form data state
  const [formData, setFormData] = useState(initialValues);

  // Calling another custom Hook - useValidation
  const { validateFieldOnChange, validateAllFields, validationProps } =
    useValidation(formData, validationSchema);

  const handleInputChange = (e) => {
    const { name, type, value, checked } = e.target;

    const parsedValue =
      type === "checkbox"
        ? checked
        : value === "true" // Convert string representation of boolean to boolean
        ? true
        : value === "false"
        ? false
        : type === "number"
        ? value === ""
          ? ""
          : parseFloat(value) // Parse as float if it's a number, allow empty string (for when user clears input)
        : value; // e.target.value

    setFormData({
      ...formData,
      [name]: parsedValue
    });

    validateFieldOnChange(name, value);
  };

  const resetForm = () => {
    const resetValues = Object.keys(formData).reduce((acc, key) => {
      acc[key] = "";
      return acc;
    }, {});

    setFormData(resetValues);
  };

  const handleSubmit = async (e) => {
    e.preventDefault();

    if (validateAllFields()) {
      try {
        await onSubmitCallback(formData);
      } catch (error) {
        console.error("Error during form submission", error);
      }
    } else {
      console.warn("Validation Failed");
      alert("Invalid Form");
    }
  };

  return {
    formData,
    handleInputChange,
    resetForm,
    handleSubmit,
    validationProps
  };
};

export default useForm;

useValidation.js Custom Hook - Centralised Validation Logic

The useValidation custom Hook centralizes validation logic, with functions like validateFieldOnChange to check fields in real-time and validateAllFields to confirm all fields meet requirements before submission.

Using validationProps, we can easily attach validation feedback to each field. Look at the input components in PersonalDetailsForm.jsx to see how the validation props are spread.

import { useState, useMemo } from "react";

const useValidation = (formData, validationSchema) => {
  const [errors, setErrors] = useState({});

  const memoValidationSchema = useMemo(
    () => validationSchema,
    [validationSchema]
  );

  // Validate field on change
  const validateFieldOnChange = (name, value) => {
    if (memoValidationSchema[name]) {
      const fieldErrors = validateField(value, memoValidationSchema[name]);
      setErrors((prevErrors) => ({
        ...prevErrors,
        [name]: fieldErrors
      }));
    }
  };

  // Validate field against validation schema
  const validateField = (value, rules) => {
    let errors = [];

    for (const rule of rules) {
      if (
        typeof rule === "object" &&
        rule.validator &&
        !rule.validator(value)
      ) {
        errors.push(rule.message); // Add error message if validation fails
      }
    }

    return errors;
  };

  // Validate all fields against their validation schema
  const validateAllFields = () => {
    const newErrors = [];
    for (const field in memoValidationSchema) {
      let fieldErrors = validateField(
        formData[field],
        memoValidationSchema[field]
      );
      if (fieldErrors.length > 0) {
        newErrors[field] = fieldErrors;
      }
    }
    setErrors(newErrors);
    return Object.keys(newErrors).length === 0;
  };

  // Validation props to use in form field component for error handling
  const validationProps = useMemo(
    () => (name) => ({
      isValid: !errors?.[name] || errors?.[name].length === 0,
      errorMessage: errors?.[name]?.[0]
    }),
    [errors]
  );

  return {
    validateFieldOnChange,
    validateAllFields,
    validationProps
  };
};

export default useValidation;

PaymentDetailsForm.jsx – Reusability

This is the component file for the ‘Payment Details’ form.

Our setup allows us to reuse useForm and useValidation in any form component such as PaymentDetailsForm.jsx without duplicating logic.

The alternative?
Without custom Hooks, each form would need its own state management and validation logic, leading to repetitive and cluttered code. Custom Hooks centralize this functionality, providing a reusable approach that follows the DRY principle.

Rules of Hooks

To ensure that Hooks work reliably, React enforces a few key rules to maintain consistent behaviour across components.

Always call Hooks at the top level of your React function: Don’t use Hooks inside loops, conditions, nested functions, or after conditional returns. This ensures that Hooks are called in the same order on every render, which React relies on for tracking state correctly.
Don’t call Hooks in event handlers or class components: Hooks are specifically designed for use in functional components or within custom Hooks, using them in other places may lead to unexpected behaviour.
Use Hooks only within React functions or custom Hooks: Custom Hooks can call other Hooks, following the same rules, as shown in our example where the useForm Hook calls the useValidation Hook.

Reusability and maintainability are essential for building scalable applications. Custom Hooks in React allow us to achieve this by encapsulating logic that can be shared across components. This leads to cleaner, more modular code that’s easier to understand, test, and extend.