DEV Community: Billy Okeyo

2025 in Review: A Year of Growth, Resilience, and Practical Engineering

Billy Okeyo — Mon, 29 Dec 2025 00:00:00 +0000

Who would’ve thought I’d open my editor on the 29th of December not to debug production or chase a failing test—but to write this recap? Because apparently, I enjoy explaining bugs to the internet.

If you told me at the beginning of 2025 that I’d spend the year writing about scalable systems, testing strategies, outages, performance optimizations, and developer excuses I would’ve believed you. If you also told me I’d still be debugging things that “worked yesterday,” I would’ve believed you even faster.

This article is a recap of everything I wrote this year: the lessons, the wins, the bugs, and the “how did this even pass code review?” moments. Think of it as a Spotify Wrapped , but for technical articles, minus the judgment (okay, maybe a little).

**System Design & Scalability — Because Your App Will Grow (Whether You’re Ready or Not)**

Summary: This year, I spent a lot of time talking about scalable backend systems — not because every app needs to handle millions of users, but because every app eventually meets its first “why is the server on fire?” moment.

How to Build Scalable Backend Systems with Python, C#, PHP and DartA practical guide to designing systems that won’t collapse the moment your app gets featured on Twitter… or worse, WhatsApp groups.

Key lesson: Scalability isn’t about overengineering — it’s about not regretting your life choices later.

Testing — Trust Issues, But Make Them Automated

Summary: Testing dominated a good part of the year, mainly because nothing builds trust issues faster than code that looks correct but isn’t.

This series walked through testing from the basics to full CI/CD integration — because “it works on my machine” is not a deployment strategy.

Unit, Integration, and End-to-End Tests — Part 1Where we learn that tests are not the enemy — flaky tests are.
Unit Testing in Depth — Part 2Small tests, big confidence.
Integration Testing in Depth — Part 3When components finally talk to each other… and start arguing.
End-to-End Testing in Depth — Part 4Testing your app the same way users break it.
The Testing Pyramid & CI/CD — Part 5The moment you realize automation saves both time and sanity.

Key lesson: Tests don’t slow you down — debugging production issues does.

Performance & Tooling — Making Code Faster Without Sacrificing Sleep

Summary: Performance optimization showed up in different forms this year — from modern runtimes to build optimizations. Because sometimes the app isn’t slow… it’s just doing unnecessary work very enthusiastically.

Diving into WebAssembly: What It Is and Why It MattersFor when JavaScript alone just isn’t fast enough.
Tree Shaking in TypeScriptRemoving code you forgot existed but was still shipped to production.

Key lesson: If users say your app is slow, they’re probably right. The logs just haven’t confessed yet.

Engineering Culture — Because Code Is Written by Humans (Flawed Ones)

Summary: Not everything this year was serious architecture talk. Some articles leaned into the very human side of software development — where excuses are plentiful and accountability is… negotiable.

Top 10 Developer Excuses When Code BreaksA humorous breakdown of things we’ve all said — and what actually went wrong.

Key lesson: If you’ve never blamed the cache, the network, or “some weird edge case,” are you even a developer?

Industry Case Studies — Learning the Hard Way (So You Don’t Have To)

Summary: One of the most impactful pieces this year was breaking down a real-world outage — because nothing teaches engineering humility like watching large systems fail in creative ways.

What Engineers Can Learn From the Cloudflare OutageA reminder that one bad configuration can humble the biggest companies.

Key lesson: Distributed systems don’t fail loudly — they fail politely, globally, and at the worst possible time.

What 2025 Really Taught Me

If I had to summarize the year in engineering truths:

Scalability matters before users complain.
Tests are cheaper than apologies.
Performance issues hide in plain sight.
Systems fail — preparation determines whether you panic or recover.
Developers are predictable creatures with unpredictable bugs.

Looking Ahead

In the next year, expect:

More real-world case studies
Deeper dives into distributed systems and cloud patterns
Practical articles you can actually apply on Monday morning

Thank you for reading, sharing, and occasionally finding bugs in my examples (yes, I see you).

Here’s to another year of writing code, fixing mistakes, and pretending we knew what we were doing all along.

What Engineers Can Learn From the Cloudflare Outage (November 2025)

Billy Okeyo — Fri, 21 Nov 2025 00:00:00 +0000

How a single oversized configuration file brought down parts of the internet and why this matters for every engineering team.

On November 18, 2025, the internet shook a little.

Cloudflare, the massive networking and security platform powering millions of websites globally, experienced a major outage that resulted in widespread 5xx errors across the internet. For several hours, key services like CDN routing, Workers KV, Access authentication, and even Cloudflare’s own dashboard were degraded.

In their official incident report , Cloudflare broke down exactly what happened, and the root cause was surprisingly small and deceptively simple:

A configuration file grew larger than expected, violated a hidden assumption in the proxy code, and triggered runtime panics across the global edge.

This incident is a powerful case study in modern distributed systems. Let’s break down what went wrong — and why engineers everywhere should take note.

What Actually Happened? A Chain Reaction From One Oversized File

The root cause began with a permissions change in Cloudflare’s ClickHouse database cluster , which led to duplicate rows in a dataset used by their Bot Management engine. That duplication caused the generated “feature file”, a config-like file that proxies rely on to double in size.

Here’s where assumptions came back to haunt them:

Cloudflare’s proxy engine expected a maximum of 200 features.
The new file exceeded that limit.
An .unwrap() in their Rust-based FL2 proxy assumed the file would always be valid.
That assumption failed — the code panicked — resulting in cascading 5xx failures.

As Cloudflare noted in their report, this caused two types of breakage across their edge:

FL2 proxies (new engine): Panicked → produced 5xx errors
FL proxies (old engine): Failed to process bot scores → defaulted to zero → broke logic in Access, rules, authentication, and security products

To make things even more confusing, Cloudflare’s status page (hosted externally) briefly went offline too, creating a misleading early hypothesis that the outage was a massive DDoS attack.

It wasn’t. It was configuration drift.

Why This Seemingly Small Bug Became a Big Internet Event

Config files have become “just another part of the deployment pipeline,” especially in cloud platforms where machine-generated metadata drives features. But Cloudflare’s outage shows:

Config is not static
Config can be corrupted
Config needs validation just like code

Because this file was distributed globally across tens of thousands of Cloudflare servers, a single flawed generation step caused a worldwide issue within minutes.

Distributed systems amplify mistakes — both good ones and bad ones.

Key Engineering Lessons We Should All Learn

1. Never rely on hidden assumptions

Cloudflare’s proxy code assumed the feature file would never exceed a certain size. That “should never happen” moment is often the birthplace of outages.

Lesson: Add explicit limits, schema checks, and sanity validations to all config ingestion paths.

2. Configuration is part of your software supply chain

The feature file was generated, replicated, and consumed automatically — no human intervention. That makes it just as risky as code.

Lesson: Treat configuration pipelines as first-class citizens: test them, validate them, gate them.

3. Build for graceful degradation, not hard crashes

A single .unwrap() took down parts of the internet.

Lesson: Fail softly. If config is invalid, degrade safely, skip rules, or revert to defaults — don’t panic.

4. Feature flags and kill switches are essential

Cloudflare themselves acknowledged the need for a more robust kill-switch system in their follow-up plans.

Lesson: Every modern engineering team should have:

global feature kill switches
fast configuration rollback
manual override options

5. Monitoring needs context, not just alarms

Many engineers watching the outage thought it was an external attack. Alerting didn’t tell them where the failure was coming from, just that everything was “down.”

Lesson: Monitoring should distinguish between:

origin failure
edge failure
config failure
auth failure
internal propagation issues

Context reduces misdiagnosis.

6. Observability tools must be lightweight during crises

During recovery, Cloudflare reported that their debugging systems started consuming high CPU, which slowed other mission-critical services.

Lesson: Your troubleshooting tools must use minimal resources when the system is stressed.

7. Transparency helps the whole industry learn

Cloudflare’s detailed post-mortem is a model for engineering culture. Their openness helps engineers worldwide understand real failure modes in large-scale systems.

Lesson: Share your failures. They help others avoid the same mistakes.

The Bigger Picture: Why This Incident Matters

Cloudflare’s outage wasn’t just a story about a config file. It was a reminder of how fragile the modern internet can be:

We automate everything
We trust our pipelines
We deploy continuously
We assume schemas won’t change
We rely on millions of machines making the same decision correctly

But when the assumptions underneath those systems break, failures propagate at machine speed.

For engineers, SREs, DevOps teams, and platform architects, this incident underscores a fundamental truth:

Your system is only as resilient as your least-validated assumption.

Final Thoughts

Cloudflare’s outage was a blip in the timeline of the internet, but the lessons are timeless.

Distributed systems will always fail, the question is how gracefully they fail, how quickly they recover, and how deeply the organization learns from the event.

Cloudflare’s transparency, analysis, and remediation steps set a strong example for engineering teams everywhere.

Stripe Connect Integration Guide — Standard, Express, and Custom Accounts Explained (with Laravel, C#, and Python Examples)

Billy Okeyo — Tue, 21 Oct 2025 00:00:00 +0000

Stripe offers a powerful ecosystem for building payment platforms , marketplaces , and financial applications. One of its most powerful products, Stripe Connect , allows you to facilitate payments between multiple parties while maintaining flexibility over branding, compliance, and user experience.

Choosing between Standard , Express , and Custom accounts is one of the most important architectural decisions you’ll make when designing a payment platform. This guide combines a step-by-step tutorial and deep technical analysis to help you understand and implement each type.

What Is Stripe Connect?

Stripe Connect is designed for platforms that process payments on behalf of others. It enables you to connect user accounts (called Connected Accounts ) to your Platform Account so you can:

Collect payments from customers
Distribute payouts to vendors, lenders, or service providers
Optionally collect platform fees

Your platform never needs to hold funds directly (unless you design it to), and Stripe handles the movement of money under the hood.

Connected Accounts Overview

Each connected account represents a business, seller, or user on your platform. Depending on how much control and responsibility you want, you’ll choose between:

Standard — Stripe handles almost everything.
Express — Stripe handles compliance, you handle limited UX.
Custom — You handle everything; Stripe is invisible to your users.

Feature / Aspect	Standard	Express	Custom
Ownership of Stripe Account	User owns and manages their Stripe account directly.	User gets a lightweight managed account. Stripe handles UI for onboarding and dashboards.	Full control; your platform owns the payment experience. Users never see Stripe.
KYC / Onboarding	Handled entirely by Stripe via the user’s Stripe dashboard.	Stripe-hosted onboarding flow with minimal setup.	You collect all KYC data through your own UI and pass it to Stripe’s API.
Dashboard Access	User uses Stripe’s own dashboard.	Limited dashboard (Stripe Express Dashboard).	No dashboard; your app must display balances, transactions, etc.
Compliance Responsibility	Stripe handles everything.	Stripe handles most KYC and compliance.	You are responsible for collecting and transmitting KYC data.
Control over UI/UX	Minimal; users leave your app to manage payments.	Moderate; Stripe provides branded but embeddable flows.	Full; completely white-labeled experience.
Ideal Use Case	Marketplaces where users already have Stripe accounts.	Platforms needing simple onboarding (e.g., gig apps).	Fintech, lending, or platforms needing deep financial workflows.

Architectural Overview

All three integration types share a common flow:

Customer → Your Platform → Connected Account → Bank Payout

However, the control points differ :

With Standard , Stripe owns the UX and dashboard.
With Express , Stripe hosts onboarding and dashboard, but your platform manages relationships.
With Custom , your platform builds everything: UI, onboarding, payouts, and reporting.

Step-by-Step Implementation by Account Type

Let’s look at how to implement each account type with C# , Laravel (PHP) and Python examples and understand their implications.

Standard Accounts — Easiest Setup, Minimal Control

Concept

Standard accounts are the simplest to integrate. Users connect their own existing Stripe accounts using OAuth. Stripe handles compliance, payouts, and reporting. Your platform receives a small application fee from each transaction.

Use Case

Ideal for marketplaces or SaaS platforms where users already have Stripe accounts and prefer to manage their own dashboards.

Implementation

C

var accountLink = await stripe.AccountLinks.CreateAsync(new AccountLinkCreateOptions {
    Account = connectedAccountId,
    RefreshUrl = "https://your-platform.com/reauth",
    ReturnUrl = "https://your-platform.com/success",
    Type = "account_onboarding",
});

Laravel (PHP)

$accountLink = \Stripe\AccountLink::create([
    'account' => $connectedAccountId,
    'refresh_url' => route('stripe.reauth'),
    'return_url' => route('stripe.success'),
    'type' => 'account_onboarding',
]);

Python

import stripe
stripe.api_key = "sk_test_..."

account_link = stripe.AccountLink.create(
    account=connected_account_id,
    refresh_url="https://your-platform.com/reauth",
    return_url="https://your-platform.com/success",
    type="account_onboarding"
)

Pros and Cons

Pros

Minimal setup
Stripe handles everything (KYC, compliance, payouts)
Reduced liability

Cons

Limited branding control
Users must leave your platform to manage payments
Harder to create a unified experience

Express Accounts — Fast Onboarding, Shared Control

Concept

Express accounts strike a balance between simplicity and control. You manage account creation and linking, but Stripe handles onboarding and provides a lightweight dashboard for your users.

Use Case

Perfect for gig or service platforms (like driver or freelancer apps) where quick onboarding and basic payout visibility are key.

Implementation

C

var account = await stripe.Accounts.CreateAsync(new AccountCreateOptions {
    Type = "express",
    Country = "US",
    Email = "user@example.com"
});

var link = await stripe.AccountLinks.CreateAsync(new AccountLinkCreateOptions {
    Account = account.Id,
    RefreshUrl = "https://yourapp.com/reauth",
    ReturnUrl = "https://yourapp.com/complete",
    Type = "account_onboarding"
});

Laravel (PHP)

$account = \Stripe\Account::create([
    'type' => 'express',
    'country' => 'US',
    'email' => $request->input('email'),
]);

$link = \Stripe\AccountLink::create([
    'account' => $account->id,
    'refresh_url' => route('stripe.reauth'),
    'return_url' => route('stripe.success'),
    'type' => 'account_onboarding',
]);

Python

account = stripe.Account.create(
    type="express",
    country="US",
    email="user@example.com"
)

link = stripe.AccountLink.create(
    account=account.id,
    refresh_url="https://yourapp.com/reauth",
    return_url="https://yourapp.com/complete",
    type="account_onboarding"
)

Pros and Cons

Pros

Faster onboarding
Stripe handles compliance and verification
Users get access to payout history via the Express dashboard

Cons

Limited customization
Stripe branding remains visible
Less flexibility over reporting or custom payout logic

Custom Accounts — Full Control, Full Responsibility

Concept

Custom accounts are designed for white-labeled platforms. Your app controls everything : onboarding, KYC collection, balances, and payouts. Stripe is completely invisible to the end user.

Use Case

Ideal for fintech, embedded finance, lending, or any system that requires deep integration and custom user experiences.

Implementation

C

accountOptions = new AccountCreateOptions {
    Type = "custom",
    Country = "US",
    Email = data.Email.ToLower(),
    Capabilities = new AccountCapabilitiesOptions {
        CardPayments = new AccountCapabilitiesCardPaymentsOptions { Requested = true },
        Transfers = new AccountCapabilitiesTransfersOptions { Requested = true }
    },
    TosAcceptance = new AccountTosAcceptanceOptions {
        Date = DateTimeOffset.UtcNow.ToUnixTimeSeconds(),
        Ip = httpContext.Connection.RemoteIpAddress.ToString()
    }
};

var account = await stripe.Accounts.CreateAsync(accountOptions);

Laravel (PHP)

$account = \Stripe\Account::create([
    'type' => 'custom',
    'country' => 'US',
    'email' => strtolower($data['email']),
    'capabilities' => [
        'card_payments' => ['requested' => true],
        'transfers' => ['requested' => true],
    ],
    'tos_acceptance' => [
        'date' => time(),
        'ip' => request()->ip(),
    ],
]);

Python

account = stripe.Account.create(
    type="custom",
    country="US",
    email=data["email"].lower(),
    capabilities={
        "card_payments": {"requested": True},
        "transfers": {"requested": True},
    },
    tos_acceptance={
        "date": int(time.time()),
        "ip": request.remote_addr,
    }
)

Fund Flow Example

+--------------------------------------+
| Platform (You) |
| No direct money handling |
+--------------------+-----------------+
                     |
                     ▼
          Create & Manage Connected Accounts
                     |
   +--------------------------------------+
   | Connected Account (Business) |
   | 💵 Has Stripe balance, bank info |
   | 🧾 Disburses and collects funds |
   +--------------------------------------+

Money Movement

IN: Customer → Connected Account (via ACH/Card)
OUT: Connected Account → Bank (payouts)
Platform orchestrates, Stripe moves the money

Checking Balances

Python

balance = stripe.Balance.retrieve(stripe_account=account_id)

Laravel (PHP)

$balance = \Stripe\Balance::retrieve([], ['stripe_account' => $accountId]);

C

var balance = await stripe.Balance.GetAsync(
    new BalanceGetOptions(),
    new RequestOptions { StripeAccount = accountId }
);

Compliance Responsibilities

Responsibility	Standard	Express	Custom
KYC	Stripe	Stripe	You
Tax Reporting	Stripe	Stripe	You
PCI Compliance	Stripe-hosted	Shared	Mostly you
Dispute Handling	Stripe	Shared	You
Branding	Stripe	Partial	Fully yours

Tip: For Custom accounts, implement Stripe Identity , webhooks , and Stripe Radar to automate verification and fraud detection.

Choosing the Right Integration Type

Scenario	Recommended Type
Marketplace with existing Stripe users	Standard
Platform needing fast onboarding	Express
Fintech, lending, or white-labeled finance	Custom

Strategic Considerations

Time-to-market: Standard < Express < Custom
Compliance load: Stripe-heavy → Custom-heavy
Branding control: Minimal → Full
Revenue potential: Low (Standard) → High (Custom)

Final Thoughts

Every Stripe Connect integration represents a trade-off between control , compliance , and complexity :

Standard — easiest to deploy, lowest control
Express — balanced control and simplicity
Custom — ultimate flexibility with greater responsibility

If your goal is speed , start with Express. If your goal is brand control and scalability , build with Custom.

Either way, Stripe Connect gives you a future-proof foundation for managing payments, onboarding users, and creating rich financial experiences all through powerful APIs available across languages.

The Testing Pyramid: Wrapping Up with CI/CD and Best Practices - Part 5

Billy Okeyo — Fri, 19 Sep 2025 00:00:00 +0000

Software testing is more than writing a few unit tests and hoping for the best. To deliver reliable software, teams need a balanced testing strategy — one that combines Unit, Integration, and End-to-End (E2E) tests in the right proportions. This is where the Testing Pyramid comes in.

In this final part of our testing series, we’ll:

Understand the Testing Pyramid model.
Explore how to balance different types of tests.
Learn how to integrate testing into CI/CD pipelines.
Review best practices for building a sustainable testing culture.

The Testing Pyramid Explained

The Testing Pyramid (popularized by Mike Cohn) is a metaphor for structuring automated tests:



        ▲
        | End-to-End (fewest, slowest)
        |
        | Integration (moderate amount, balanced)
        |
        | Unit Tests (largest base, fastest)
        ▼

1. Unit Tests (Foundation)

Fast, cheap, and precise.
Cover small pieces of logic in isolation.
Should make up 60–70% of your automated test suite.

Example: Testing a function that calculates interest rates.

2. Integration Tests (Middle Layer)

Validate how components interact.
Cover database queries, API requests, or service orchestration.
Should make up 20–30% of your test suite.

Example: Ensuring your API endpoint correctly fetches data from the database and formats the response.

3. End-to-End Tests (Top)

Simulate real user flows across the full stack.
Catch bugs unit or integration tests can’t.
Should make up 10–15% of your suite (because they’re slow and expensive).

Example: A test where a user logs in, adds a product to their cart, and completes checkout.

Integrating Tests into CI/CD Pipelines

Automated tests are only valuable if they’re run consistently. Modern software teams embed them into CI/CD pipelines.

Step 1: Run Unit Tests Early

Execute on every commit or pull request.
Fail fast: block merges if unit tests fail.

Step 2: Run Integration Tests on Build/Deploy

Run after the app compiles successfully.
Can use a containerized test environment with mock or staging databases.

Step 3: Run End-to-End Tests on Staging

Triggered before production deployment.
Some teams run smoke E2E tests in production (carefully) to ensure critical flows still work.

Example CI/CD Flow (GitHub Actions / GitLab / Jenkins):

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
      - name: Run unit tests
        run: npm test -- --unit
      - name: Run integration tests
        run: npm test -- --integration
      - name: Run e2e tests
        run: npm run test:e2e

Best Practices for a Balanced Testing Strategy

1. Follow the Pyramid, Not the Ice Cream Cone

Too many E2E tests = slow, brittle pipeline.
Too few unit tests = shaky foundation.
Balance is key.

2. Use Test Doubles Wisely

Mocks/Stubs in unit tests to isolate dependencies.
Minimal mocking in integration tests — rely on real services where possible.

3. Make Tests Deterministic

Tests should always produce the same result.
Avoid flaky tests (caused by race conditions, timeouts, or external dependencies).

4. Keep Tests Fast

Aim for seconds, not minutes.
Developers won’t run slow tests locally.

5. Automate Everything in CI/CD

Manual testing has its place, but regression checks must be automated.
CI/CD pipelines should be your safety net before production.

6. Monitor and Improve Test Coverage

Coverage isn’t everything, but low coverage usually indicates gaps.
Focus on critical paths rather than chasing 100%.

7. Treat Tests as Code

Tests should be maintainable, reviewed, and refactored like production code.
Avoid “test rot” where tests become outdated or ignored.

Final Thoughts

The journey from unit → integration → E2E tests gives you confidence at every level of your system.

Unit tests keep your building blocks solid.
Integration tests ensure the blocks fit together.
E2E tests confirm the entire structure works as intended.

By following the Testing Pyramid , integrating tests into CI/CD pipelines , and practicing discipline in writing effective tests, you’ll achieve:

Faster feedback loops.
Fewer production bugs.
Higher developer confidence.
Happier end-users.

Testing isn’t just about catching bugs, it’s about building trustworthy software at scale.

Next Steps for You:

Audit your current test suite.
See if you’re over-relying on one type of test.
Gradually reshape your suite into a pyramid , not an ice cream cone.

End-to-End (E2E) Testing in Depth - Part 4

Billy Okeyo — Fri, 12 Sep 2025 00:00:00 +0000

If unit tests check individual functions, and integration tests check how those functions work together, end-to-end (E2E) tests take it all the way: They simulate real user workflows from start to finish, ensuring the entire application stack works as expected.

E2E testing is about validating the system as a whole , covering everything from frontend to backend, database, APIs, and sometimes even external services.

What Are E2E Tests?

E2E tests replicate user behavior and verify that the system responds correctly. Think of them as automated users interacting with your app.

Example workflows tested in E2E:

User logs in → Dashboard loads correctly.
User creates a record → It’s stored in DB → Appears in the UI.
Checkout flow in an e-commerce app → Product added → Payment processed → Order confirmed.

Why E2E Tests Matter

Validate Real Workflows → Ensure the system behaves like users expect.
Catch System-Wide Failures → Config issues, routing errors, DB schema mismatches.
Test Critical Paths → Login, payments, onboarding, search, etc.
Provide Business Confidence → Stakeholders see features working as intended.

Characteristics of E2E Tests

High Coverage – Test across the full stack.
Slowest of All Tests – Often run in CI/CD pipelines, not during active coding.
Brittle – Small UI changes can break tests, so balance is key.
Mimic Real User Behavior – Often browser-driven or API-driven.

Side-by-Side Examples

Scenario:

A user visits a web app, logs in, and sees their profile page with their name.

Python (Selenium + pytest)

# test_e2e_login.py
from selenium import webdriver
from selenium.webdriver.common.by import By
import pytest

@pytest.fixture
def driver():
    driver = webdriver.Chrome()
    yield driver
    driver.quit()

def test_login_flow(driver):
    driver.get("http://localhost:5000/login")

    driver.find_element(By.NAME, "username").send_keys("alice")
    driver.find_element(By.NAME, "password").send_keys("password123")
    driver.find_element(By.ID, "login-button").click()

    profile_name = driver.find_element(By.ID, "profile-name").text
    assert profile_name == "Alice"

C# (Selenium + xUnit)

using Xunit;
using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;

public class LoginE2ETests
{
    [Fact]
    public void Login_ShowsProfilePage()
    {
        using var driver = new ChromeDriver();
        driver.Navigate().GoToUrl("http://localhost:5000/login");

        driver.FindElement(By.Name("username")).SendKeys("alice");
        driver.FindElement(By.Name("password")).SendKeys("password123");
        driver.FindElement(By.Id("login-button")).Click();

        var profileName = driver.FindElement(By.Id("profile-name")).Text;
        Assert.Equal("Alice", profileName);
    }
}

TypeScript (Playwright / Cypress)

(Playwright example below — Cypress would be very similar)

// login.e2e.test.ts
import { test, expect } from "@playwright/test";

test("user can login and see profile page", async ({ page }) => {
  await page.goto("http://localhost:3000/login");

  await page.fill("input[name=username]", "alice");
  await page.fill("input[name=password]", "password123");
  await page.click("#login-button");

  const profileName = await page.textContent("#profile-name");
  expect(profileName).toBe("Alice");
});

PHP (Laravel Dusk for browser automation)

// tests/Browser/LoginTest.php
<?php

namespace Tests\Browser;

use Laravel\Dusk\Browser;
use Tests\DuskTestCase;

class LoginTest extends DuskTestCase
{
    public function testUserCanLoginAndSeeProfile()
    {
        $this->browse(function (Browser $browser) {
            $browser->visit('/login')
                    ->type('username', 'alice')
                    ->type('password', 'password123')
                    ->press('Login')
                    ->assertSee('Alice');
        });
    }
}

Comparison Table

Aspect	E2E Testing Goal	Python (Selenium)	C# (Selenium + xUnit)	TypeScript (Playwright/Cypress)	PHP (Laravel Dusk)
Scope	Full user workflow (UI → backend → DB)	✅	✅	✅	✅
Tools	Selenium	Selenium	Playwright/Cypress	Dusk (browser automation)
Speed	Slow (browser interaction)	Slow	Medium	Medium/Fast
Confidence	Highest — validates the system end-to-end	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐
Best For	Login flows, payments, user journeys	UI + API flows	UI + API flows	Fullstack web apps	Laravel apps

Best Practices for Writing Effective E2E Tests

Test Critical User Journeys Only
- Focus on login, checkout, payments, onboarding, etc.
- Don’t waste time E2E testing every small feature.
Keep Tests Deterministic
- Avoid flakiness by controlling test data.
- Seed databases with known test records.
Use Test-Specific Environments
- Run E2E tests in staging or CI environments.
- Isolate from production data and services.
Clean Up After Tests
- Ensure created records (users, orders) are rolled back or deleted.
Use IDs and Stable Selectors
- Avoid brittle selectors like div:nth-child(3).
- Use unique IDs or data-test attributes.
Parallelize and Optimize
- Run tests in parallel (e.g., Playwright, Cypress).
- Keep them minimal to avoid bloated CI runs.
Combine with Unit & Integration Tests
- Don’t rely solely on E2E.
- Use a test pyramid strategy:
Monitor and Review Regularly
- E2E tests can get brittle.
- Review and refactor when the UI or workflows change.

Key Takeaways

E2E tests replicate the user’s journey and validate the full system.
They are slower and more brittle , but they give the highest level of confidence.
Use them sparingly for critical paths (login, payments, core workflows).
Balance your test pyramid:
Choose the right tools for your stack (Selenium, Playwright, Cypress, Dusk).
Follow best practices to keep tests reliable and maintainable.

Integration Testing in Depth : Test components working together (and not hate it) Part 3

Billy Okeyo — Fri, 05 Sep 2025 00:00:00 +0000

Integration tests sit in the sweet spot between tiny, fast unit tests and slow, expensive end-to-end tests. They verify that multiple parts of your system cooperate correctly e.g., your API layer talks to the DB the way you expect, background jobs persist state, or your service correctly handles responses from an external API.

This post is a practical, language-agnostic guide to integration testing, plus side-by-side, runnable patterns for Python , C# (.NET), TypeScript (Node/Express) and PHP (Laravel) so you can immediately apply the ideas in your stack.

What integration tests are (and are not)

Integration tests verify behavior across component boundaries, multiple classes, modules, services or infrastructure pieces that would not be exercised by a unit test.

They are not:

A replacement for unit tests (they’re slower & coarser).
Full UI-driven E2E tests (unless you intentionally include the UI).

They are good for:

Verifying DB reads/writes via your data access layer.
Testing service-to-service interactions.
Ensuring message queue jobs and workers together produce expected state.
Checking how your app handles external API payloads (with a mock or stub of that API).

Goals & tradeoffs

Goals

Catch bugs that only appear when components are wired together.
Validate API contracts inside your own system.
Give more realistic coverage than unit tests.

Tradeoffs

Slower than unit tests.
Harder to make fully deterministic (external services, timing).
Need careful setup/teardown to stay reliable.

Core patterns & recommendations

1. Use realistic but controlled dependencies

Prefer a real database (or the same engine, e.g., PostgreSQL) rather than mocking DB calls.
For external services (payment gateways, email providers), use service doubles : a local mock server, WireMock, or HTTP interceptors (nock, responses, Http::fake). Don’t call the live service in CI.

2. Isolate tests

Run each test in a transaction and roll it back (if possible), or recreate schema between tests.
Or give each test its own ephemeral database (unique DB name/per-worker) when running tests in parallel.

3. Keep tests focused

Each integration test should exercise a meaningful interaction or flow (e.g., API -> DB, or API -> external-service-stub -> DB), not every possible path.

4. Seed deterministic test data

Use builders/fixtures to create known state. Avoid random data unless seeded.

5. Manage long-running processes

For queues/workers, either run workers synchronously in tests, use a fake queue, or spin up a test worker process in CI.

6. Use testcontainers or docker-compose in CI

For close-to-production fidelity, use Testcontainers (or docker-compose) to provision real DBs and services in CI.

7. Avoid flaky tests

No sleeps/time-based races. Use blocking signals, polling with timeouts, or deterministic stubs.

When to mock vs when to use real services

Real DB : Prefer real DB engine (Postgres, MySQL). SQLite is OK for many cases but can mask engine-specific issues.
External APIs : Mock in integration tests. Use contract testing (Pact) to keep mocked expectations in-sync.
Caches/Queues : Use in-memory or test doubles unless you must validate the actual middleware behavior.

Observability: make debugging failing integration tests easy

Emit structured logs during tests (include request IDs).
Capture and print responses and DB state on failure.
Keep helpful assertion messages.

Checklist: test lifecycle

Create test environment (DB, migrations applied).
Seed minimal deterministic data.
Execute action via real interfaces (HTTP client, direct call).
Assert state persisted, side effects happened (e.g., DB row created, message pushed, HTTP call stubbed).
Tear down (transaction rollback, truncate tables, drop DB).

Common pitfalls & fixes

Flaky tests : avoid sleep-based waiting; use retry-with-timeout polling and assert deterministically.
Slow setup : keep per-test setup minimal; use transactional rollback where possible.
Parallel test collisions : give tests separate DBs or use unique table prefixes.
“Works locally but fails in CI” : mirror CI environment locally using Docker/Testcontainers and run tests there.

Example integration tests (side-by-side)

Scenario used across examples:

A POST /users endpoint that creates a user record in the database and triggers an HTTP call to an external email service (welcome email). Integration test will create a user via HTTP, verify DB row exists, and verify the email call was made (mocked).

Python — FastAPI + SQLAlchemy + pytest + requests-mock

Notes: Use sqlite:///:memory: or a Testcontainers Postgres for higher fidelity in CI. requests-mock stubs outgoing HTTP calls.

# app.py (pseudo)
from fastapi import FastAPI, Depends
from sqlalchemy import create_engine
from sqlalchemy.orm import sessionmaker

app = FastAPI()

# App factory to pass different DB URLs in tests
def create_app(db_url, email_service_url):
    engine = create_engine(db_url)
    Session = sessionmaker(bind=engine)
    # create tables...
    app.state.db = Session
    app.state.email_url = email_service_url

    @app.post("/users")
    def create_user(payload: dict):
        sess = app.state.db()
        user = User(name=payload["name"], email=payload["email"])
        sess.add(user); sess.commit()
        # Send welcome email via requests.post(app.state.email_url, json=...)
        return {"id": user.id}

    return app


# test_integration.py
import pytest
from fastapi.testclient import TestClient
import requests_mock
from app import create_app

@pytest.fixture
def client(tmp_path):
    # Use sqlite in-memory for speed or file DB for persistence across app
    app = create_app("sqlite:///:memory:", "http://email.test/send")
    client = TestClient(app)
    yield client

def test_create_user_and_send_email(client):
    with requests_mock.Mocker() as m:
        m.post("http://email.test/send", status_code=200, json={"ok": True})
        resp = client.post("/users", json={"name":"Alice","email":"a@example.com"})
        assert resp.status_code == 200
        user_id = resp.json()["id"]

        # Verify DB row exists (open a session)
        Session = client.app.state.db
        sess = Session()
        user = sess.query(User).filter_by(id=user_id).one_or_none()
        assert user is not None
        assert user.email == "a@example.com"

        # Verify external email call occurred
        assert m.called
        assert m.request_history[0].json() == {"to": "a@example.com", "template": "welcome"}

Tips

For CI, replace sqlite with Testcontainers Postgres: create_app(postgres_url, ...).
Use DB migrations in setup if using a real DB.

C# (.NET) — ASP.NET Core + WebApplicationFactory + InMemory DB / Testcontainer

Notes: Use WebApplicationFactory<TEntryPoint> to spin the app in tests and override service registrations for test doubles.

// In Startup.cs, app reads EmailService via IEmailService (HttpEmailService in prod)

public class TestEmailService : IEmailService {
    public List<EmailMessage> Sent = new();
    public Task SendAsync(EmailMessage msg) { Sent.Add(msg); return Task.CompletedTask; }
}

// Integration test
public class UsersIntegrationTests : IClassFixture<WebApplicationFactory<Program>> {
    private readonly WebApplicationFactory<Program> _factory;

    public UsersIntegrationTests(WebApplicationFactory<Program> factory) {
        _factory = factory.WithWebHostBuilder(builder => {
            builder.ConfigureServices(services => {
                // Replace real DB with in-memory or Testcontainer; replace email service with TestEmailService
                services.AddSingleton<IEmailService, TestEmailService>();
                // Configure EF Core to use InMemoryDatabase or connection string from Testcontainers
            });
        });
    }

    [Fact]
    public async Task PostUsers_CreatesUser_And_SendsEmail() {
        var client = _factory.CreateClient();
        var content = new StringContent("{\"name\":\"Bob\",\"email\":\"b@ex.com\"}", Encoding.UTF8, "application/json");
        var resp = await client.PostAsync("/users", content);
        resp.EnsureSuccessStatusCode();

        // Verify DB: use scope to resolve DbContext
        using(var scope = _factory.Services.CreateScope()) {
            var db = scope.ServiceProvider.GetRequiredService<AppDbContext>();
            var user = db.Users.Single(u => u.Email == "b@ex.com");
            Assert.NotNull(user);
        }

        // Verify TestEmailService captured message
        var emailService = _factory.Services.GetRequiredService<IEmailService>() as TestEmailService;
        Assert.Single(emailService.Sent);
        Assert.Equal("welcome", emailService.Sent[0].Template);
    }
}

Tips

For a real DB in CI, use Testcontainers .NET to spin up Postgres and set EF Core connection string.
Overriding services avoids brittle HTTP stubbing, and keeps assertions in-process.

TypeScript (Node/Express) — supertest + sqlite in-memory + nock

Notes: supertest issues HTTP requests to your Express app instance. Use nock to intercept outgoing HTTP.

// app.ts (pseudo)
import express from "express";
import bodyParser from "body-parser";
import { initDb } from "./db";

export function createApp(dbPath: string) {
  const app = express();
  app.use(bodyParser.json());
  const db = initDb(dbPath); // e.g., sqlite3 in-memory or file
  app.post("/users", async (req, res) => {
    const { name, email } = req.body;
    const id = await db.run("INSERT INTO users(name,email) VALUES(?,?)", [name, email]);
    // call external email service via fetch/http client
    await fetch("http://email.test/send", { method: "POST", body: JSON.stringify({ to: email, template: "welcome" }) });
    res.json({ id });
  });
  return app;
}


// test/integration.test.ts
import request from "supertest";
import nock from "nock";
import { createApp } from "../app";
import { openDb, getUserById } from "../db";

describe("POST /users", () => {
  it("creates a user and calls email service", async () => {
    const app = createApp(":memory:");
    const email = nock("http://email.test")
      .post("/send", (body) => body.to === "c@ex.com" && body.template === "welcome")
      .reply(200, { ok: true });

    const res = await request(app)
      .post("/users")
      .send({ name: "Carol", email: "c@ex.com" })
      .expect(200);

    // verify DB
    const user = await getUserById(res.body.id);
    expect(user.email).toBe("c@ex.com");

    // verify external call was made
    expect(email.isDone()).toBe(true);
  });
});

Tips

For complex schemas, use migrations in test setup or run a dedicated test DB with sqlite file per test.
For Postgres in CI, spin up DB via docker-compose or Testcontainers Node.

PHP (Laravel) — HTTP tests + RefreshDatabase + Http::fake()

Notes: Laravel has excellent integration testing helpers. RefreshDatabase runs migrations and transacts where possible. Use Http::fake() to intercept external HTTP.

// routes/api.php
Route::post('/users', [UserController::class, 'store']);

// UserController->store uses User model and Http::post('http://email.test/send', ...);


// tests/Feature/CreateUserTest.php
<?php
namespace Tests\Feature;

use Illuminate\Foundation\Testing\RefreshDatabase;
use Illuminate\Support\Facades\Http;
use Tests\TestCase;
use App\Models\User;

class CreateUserTest extends TestCase
{
    use RefreshDatabase;

    public function test_create_user_and_send_welcome_email()
    {
        Http::fake([
            'email.test/*' => Http::response(['ok' => true], 200),
        ]);

        $response = $this->postJson('/api/users', [
            'name' => 'Dan',
            'email' => 'd@ex.com',
        ]);

        $response->assertStatus(200);

        // verify DB
        $this->assertDatabaseHas('users', ['email' => 'd@ex.com']);

        // assert that an outbound call was made
        Http::assertSent(function ($request) {
            return $request->url() == 'http://email.test/send' &&
                   $request['to'] == 'd@ex.com' &&
                   $request['template'] == 'welcome';
        });
    }
}

Tips

Laravel’s RefreshDatabase will use in-memory sqlite if configured, otherwise migrate a test DB.
Use Queue::fake() to test that jobs were dispatched without executing background workers.

Practical integration testing strategies

Use transactions for isolation

Wrap each test in a DB transaction and roll back at the end. Works well when everything runs in the same DB connection.
Caveat: some ORMs/connections (e.g., tests that spawn separate processes) might not share transaction visibility.

Use in-memory DBs for speed, but test on real DBs in CI

SQLite in-memory is fast, but can behave differently (indexing, SQL dialect). Complement local tests with real-engine tests in CI using containers.

Stubbing external HTTP reliably

Python: responses or requests-mock
Node: nock
C#: WireMock.Net or replace typed HttpClient with test handler
PHP: Laravel Http::fake()

Testcontainers — real dependencies in CI

Spin up a Postgres, Redis, or Kafka container for integration tests.
Testcontainers exists for many ecosystems (Java, .NET, Node, Python wrappers).

Contract testing for cross-team APIs

Use Pact or similar to generate contracts from consumer tests and verify provider compliance in provider CI. This avoids brittle mocks and catches breaking API changes.

Background jobs & queues

Either run job handlers inline (synchronously) in tests, use fake queues that record enqueued messages, or run a worker process in CI that reads from test queue.

How many integration tests should you write?

No fixed number. Aim for:

Unit tests: many (business logic)
Integration tests: enough to cover critical integration points (DB persistence, payment flows, auth)
E2E tests: few (critical user paths)

A practical rule: write integration tests for each major DB operation and for the essential external integrations.

Debugging failing integration tests

Print request/response bodies and DB rows on failure.
Capture network traffic (or enable higher logging).
Reproduce the failing test locally with the same CI container setup (Testcontainers makes that easy).
If a test is flaky, add instrumentation and increase visibility; temporary retries mask real issues.

Sample integration test checklist

Before merging an integration test into CI:

Test uses deterministic data.
DB schema/migrations run and are applied in setup.
External dependencies are stubbed or provided by test containers.
Test cleans up (transaction rollback or truncation).
No sleeps or time-based races.
Test is focused on behavior, not implementation.

Wrapping up & next steps

Integration tests reduce the mismatch between isolated units and the full system. They give higher confidence than unit tests while being cheaper and faster than full E2E tests. When designed well they catch boundary problems early and make refactoring safer.

Next post in the series: End-to-End (E2E) Testing in Depth — we’ll cover realistic end-to-end strategies, UI-driving vs API-only E2E, test environments, flaky UI tests, and how to design low-maintenance high-value E2E checks.

Happy testing!

Unit Testing in Depth: Principles, Patterns, and Pragmatic Tactics (Part 2)

Billy Okeyo — Fri, 29 Aug 2025 00:00:00 +0000

Unit tests are the safety net that let you refactor without fear, document behavior without docs, and ship with confidence. Done well, they’re fast, reliable, and cheap to maintain. Done poorly, they’re flaky, slow, and ignored.

This is a continuation of the the Unit, Integration, and End-to-End Tests: Building Confidence in Your Software series. In case you missed it, be sure to check out the previous posts for a solid foundation. This guide goes deep into what makes a great unit test , how to structure them, how to avoid common pitfalls, and how to design code that’s easy to unit test.

What is a “Unit” (really)?

A unit is the smallest piece of behavior you care about verifying typically a function, method, or class. The unit:

Has no external I/O (no network, DB, filesystem, clock, randomness).
Has clear inputs and outputs (return value or state change).
Can be run thousands of times deterministically and quickly.

Heuristic: if your test needs network access, sleeps, or a DB, it’s probably not a unit test.

The Goal of Unit Tests

Prevent regressions close to the source of truth.
Document behavior by example.
Enable refactoring with confidence.
Encourage good design (loose coupling, small interfaces).

Qualities of Great Unit Tests (F.I.R.S.T.)

Fast – run in milliseconds; okay to run on every save/commit.
Isolated – no shared state; independent from other tests.
Repeatable – same result every run; no flakiness.
Self-validating – clear pass/fail without manual inspection.
Timely – written close to when the code is written (test-first or test-soon).

Anatomy of a Readable Test

Use Arrange–Act–Assert (AAA) or Given–When–Then. Keep one behavior per test.

test "calculate_total when valid items then returns sum minus discounts" {
  // Arrange
  items = [10, 20, 30]
  discount = 0.1
  sut = PriceCalculator() // SUT = System/Subject Under Test

  // Act
  total = sut.calculate_total(items, discount)

  // Assert
  assert_equal(54, total) // (10+20+30)=60; 10% off => 54
}

Naming patterns that scale

MethodName_WhenCondition_ShouldExpectedOutcome
Given_State_When_Action_Then_Outcome

Good names save hours of log-digging later.

What to Test (and What Not to)

Do test

Business rules and edge cases (boundaries, empties, nulls, negatives, overflows).
Error handling (exceptions, validation messages).
Idempotency and invariants (calling twice has same effect).
Serialization/parsing for your own formats.

Don’t test

Framework code you don’t control.
Trivial getters/setters (unless there’s logic).
UI layout or CSS (move to integration/E2E if needed).

Test Data Without Pain

Messy data setup is the #1 cause of unreadable tests. Use builders.

order = OrderBuilder()
          .with_item("book", 20)
          .with_item("pen", 5)
          .with_discount(0.1)
          .build()

Patterns:

Test Data Builder : fluent object construction.
Mother Object : canonical “valid” objects you tweak per test.
Parameterized tests : table-driven cases for variations.

Test Doubles: Choose the Right Tool

Not everything should be “real” in a unit test. Replace collaborators with test doubles :

Double	Purpose	Example
Dummy	Filler to satisfy signatures	`new LoggerDummy()` that’s never used
Stub	Provide canned returns	`ClockStub(now="2025-08-22")`
Spy	Record calls for later assertions	`EmailSpy.sent_to("a@b.com") == true`
Mock	Pre-programmed expectations (behavior verification)	`Expect(repo.save(order))`
Fake	Lightweight working impl	`InMemoryRepository` with a map

Guideline: Prefer stubs/spies/fakes. Use mocks when you truly care about the interaction contract (e.g., exactly one call, in a specific order). Over-mocking couples tests to implementation details.

Taming Non-Determinism (Time, Randomness, Concurrency, I/O)

Flaky unit tests usually leak non-determinism. Isolate it behind interfaces:

Time

Introduce a Clock port.

interface Clock { now(): Instant }
class SystemClock implements Clock { now() = system_now() }
class FixedClock(t) implements Clock { now() = t }

Inject FixedClock in tests.

Randomness

Wrap the RNG:

interface RandomGen { next(): int }
class SeededRandom(seed) implements RandomGen { ... }
class FixedRandom(sequence) implements RandomGen { next() = sequence.pop() }

Concurrency

Avoid real threads in unit tests. Extract logic to pure functions; test scheduling via fake executors or synchronous dispatchers.

I/O

Abstract with ports/adapters (Repository, HttpClient, FileStore). Use in-memory fakes.

Assertions that Pull Their Weight

Prefer specific asserts: assert_equal(54, total) over assert_true(total < 60).
Provide custom messages : assert_equal(54, total, "10% discount not applied").
Assert one behavior per test (multiple asserts okay if they describe one behavior).

Property-Based Tests (when examples aren’t enough)

Beyond example tests, check properties that must always hold.

Properties for calculate_total(items, d):

Non-negativity: result ≥ 0
Monotonicity: adding an item never decreases total
Discount bounds: with 0 ≤ d ≤ 1, total ≤ sum(items)

property "adding item increases total" {
  for_all(item_price > 0, items >= []) {
    before = calc(items, d=0)
    after = calc(items + [item_price], d=0)
    assert_true(after >= before)
  }
}

Use property tests to catch edge cases humans miss.

Structuring Your Test Suite

Mirror production structure : src/price/calculator.* → test/price/calculator_test.*
One SUT per file where possible.
Common helpers in test_support/ (builders, fakes, assertions).
Keep fixtures local unless truly shared.

Coverage: Useful, but Not the Goal

Track line/statement and branch coverage to find blind spots.
Don’t chase 100%. Aim for meaningful coverage of business logic and risk areas.
Complement with mutation testing if available (ensures tests can detect real changes).

Test-Driven Development (TDD): Micro-cycles that Improve Design

Red → Green → Refactor :

Red : write a failing test that expresses desired behavior.
Green : implement the simplest code to pass it.
Refactor : improve design with tests staying green.

Even if you don’t TDD all the time, using short cycles on complex logic reduces waste and over-engineering.

Common Unit Test Smells (and Fixes)

Brittle tests (fail after harmless refactors) → Assert on behavior , not internal calls/ordering (avoid over-mocking).
Mega setups (50-line arrange blocks) → Introduce builders and sensible defaults.
Hidden dependencies (time, singletons) → Add interfaces; inject Clock/Random/Config.
Flaky tests (sometimes fail) → Remove sleeps; use fixed clocks , fakes , and synchronous executors.
Logic in tests (ifs/loops) → Replace with parameterized tests or test data tables.

Worked Example (End-to-End Unit Test Thought Process)

Requirement: “Calculate order total with per-item prices, optional percentage discount, and tax applied after discount.”

Rules:

Subtotal = sum(prices)
Discounted = subtotal × (1 − discount) where 0 ≤ discount ≤ 1
Total = round_to_cents(discounted × (1 + taxRate))

Example tests

Happy path

test "applies 10% discount then 16% tax" {
  sut = PriceCalculator(taxRate=0.16)
  total = sut.total([100, 50], discount=0.10)
  // subtotal = 150; after discount = 135; with tax = 156.6
  assert_equal(156.60, total)
}

Edge cases

test "empty items yields 0" {
  assert_equal(0.00, PriceCalculator(0.16).total([], discount=0))
}

test "discount is clamped between 0 and 1" {
  assert_equal(116.00, PriceCalculator(0.16).total([100], discount=2.0)) // treated as 1.0
  assert_equal(116.00, PriceCalculator(0.16).total([100], discount=-0.5)) // treated as 0.0
}

Rounding behavior


test "rounds to nearest cent (bankers or half-up as spec'd)" {
  // define and lock rounding policy; assert explicit expected cents
}

Property

property "adding an item never decreases total when discount fixed" { ... }

Note how tests pin down rounding, clamping, and the order of operations—classic sources of real-world bugs.

Design for Testability (so unit tests are easy)

Dependency Injection : pass collaborators (Clock, Repo) via constructor/params.
Pure Functions : push logic into pure units; keep side effects at the edges.
Small Interfaces : program to ports; adapters do I/O.
Single Responsibility : smaller units are easier to test and reason about.

Performance: Keep Tests Lightning-Fast

Avoid costly setup; prefer in-memory collaborators.
No sleeps/timeouts; fake the clock/scheduler.
Run unit tests in a watch mode locally; keep CI under seconds for this suite.

When to Delete or Rewrite Tests

Requirements changed → Update tests to reflect new truth.
Test asserts an implementation detail → Rewrite to assert behavior.
Chronic flakiness → Fix root cause or remove; flaky tests destroy trust.

A Minimal Template You Can Reuse

suite PriceCalculatorTests:
  setup:
    tax = 0.16
    sut = PriceCalculator(taxRate=tax)

  test "returns zero for empty items":
    expect sut.total([], discount=0) == 0.00

  test "applies discount before tax":
    expect sut.total([100], discount=0.10) == 104.40

  test "clamps invalid discounts":
    expect sut.total([100], discount=2.0) == 116.00

  test "non-negativity property":
    for_all item_lists:
      expect sut.total(item_lists, discount=0) >= 0

Checklist: Before You Commit

Test name reads like a spec (explains when/then).
Only one behavior under test.
No hidden I/O/time/randomness.
Clear, specific assertions (with messages).
Fast (ms), repeatable, independent.
Data setup is minimal and readable (builder/fixtures).

Side-by-Side Examples

We’ll use a simple scenario:

Function to calculate the discounted price given an original price and discount percentage.

Python (pytest / unittest)

# discount.py
def apply_discount(price: float, discount: float) -> float:
    if discount < 0 or discount > 100:
        raise ValueError("Discount must be between 0 and 100")
    return price - (price * discount / 100)

# test_discount.py
import pytest
from discount import apply_discount

def test_apply_discount_valid():
    assert apply_discount(100, 10) == 90

def test_apply_discount_zero_discount():
    assert apply_discount(100, 0) == 100

def test_apply_discount_invalid():
    with pytest.raises(ValueError):
        apply_discount(100, 150)

C# (xUnit)


// Discount.cs
public class Discount
{
    public static decimal ApplyDiscount(decimal price, decimal discount)
    {
        if (discount < 0 || discount > 100)
            throw new ArgumentException("Discount must be between 0 and 100");

        return price - (price * discount / 100);
    }
}

// DiscountTests.cs
using Xunit;

public class DiscountTests
{
    [Fact]
    public void ApplyDiscount_ValidDiscount_ReturnsDiscountedPrice()
    {
        var result = Discount.ApplyDiscount(100, 10);
        Assert.Equal(90, result);
    }

    [Fact]
    public void ApplyDiscount_ZeroDiscount_ReturnsSamePrice()
    {
        var result = Discount.ApplyDiscount(100, 0);
        Assert.Equal(100, result);
    }

    [Fact]
    public void ApplyDiscount_InvalidDiscount_ThrowsException()
    {
        Assert.Throws<ArgumentException>(() => Discount.ApplyDiscount(100, 150));
    }
}

TypeScript (Jest)

// discount.ts
export function applyDiscount(price: number, discount: number): number {
  if (discount < 0 || discount > 100) {
    throw new Error("Discount must be between 0 and 100");
  }
  return price - (price * discount / 100);
}

// discount.test.ts
import { applyDiscount } from "./discount";

test("applyDiscount with valid discount", () => {
  expect(applyDiscount(100, 10)).toBe(90);
});

test("applyDiscount with zero discount", () => {
  expect(applyDiscount(100, 0)).toBe(100);
});

test("applyDiscount with invalid discount", () => {
  expect(() => applyDiscount(100, 150)).toThrow();
});

PHP (Laravel / PHPUnit)

// app/Services/DiscountService.php
<?php
namespace App\Services;

class DiscountService {
    public function applyDiscount(float $price, float $discount): float {
        if ($discount < 0 || $discount > 100) {
            throw new \InvalidArgumentException("Discount must be between 0 and 100");
        }
        return $price - ($price * $discount / 100);
    }
}


// tests/Unit/DiscountServiceTest.php
<?php
namespace Tests\Unit;

use App\Services\DiscountService;
use PHPUnit\Framework\TestCase;

class DiscountServiceTest extends TestCase
{
    public function testApplyDiscountValid() {
        $service = new DiscountService();
        $this->assertEquals(90, $service->applyDiscount(100, 10));
    }

    public function testApplyDiscountZero() {
        $service = new DiscountService();
        $this->assertEquals(100, $service->applyDiscount(100, 0));
    }

    public function testApplyDiscountInvalid() {
        $this->expectException(\InvalidArgumentException::class);
        $service = new DiscountService();
        $service->applyDiscount(100, 150);
    }
}

Comparison Table

Aspect	Unit Test Goal	Python (pytest)	C# (xUnit)	TypeScript (Jest)	PHP (PHPUnit)
Framework	Testing tool used	pytest/unittest	xUnit	Jest	PHPUnit
Isolation	Tests only the function logic	✅	✅	✅	✅
Error Handling	Verify invalid inputs raise exceptions/errors	`pytest.raises`	`Assert.Throws`	`toThrow()`	`expectException`
Speed	Very fast, no external dependency	⚡⚡⚡	⚡⚡⚡	⚡⚡⚡	⚡⚡⚡

Key Takeaways

Unit tests are your first safety net : they guarantee that individual building blocks work correctly.
They should be small, isolated, and run fast.
Mocks and stubs are often used when dependencies exist.
Every language has its idiomatic testing framework , but the philosophy is the same.

What’s Next in the Series

Up next: Integration Testing in Depth — choosing boundaries, taming real dependencies, keeping tests reliable without turning them into E2E. Stay tuned!

Unit, Integration, and End-to-End Tests: Building Confidence in Your Software

Billy Okeyo — Fri, 22 Aug 2025 00:00:00 +0000

When building modern software systems, writing tests isn’t just about catching bugs, it’s about creating confidence. Confidence that your logic works, confidence that features integrate well, and confidence that the entire system behaves as expected for real users.

In the world of software testing, three types of tests are most commonly discussed: unit tests , integration tests , and end-to-end (E2E) tests. Each serves a distinct purpose, each has strengths and trade-offs, and together they form the foundation of a reliable testing strategy.

This article provides a comprehensive, language-agnostic breakdown of these three pillars of testing, highlighting their importance, differences, and best practices.

1. Unit Tests: Validating the Smallest Pieces

Definition Unit tests focus on testing the smallest units of code in isolation, typically functions, methods, or classes. The goal is to verify that a specific piece of logic behaves exactly as intended.

Why they matter

They provide fast feedback since they run quickly.
They serve as documentation for how a function or module is supposed to work.
They help catch regressions early , before code reaches higher environments.

Example Scenario Imagine you’re building a shopping cart system. A unit test might check that:

Adding an item updates the cart total correctly.
Removing an item decreases the count.
Discount calculations apply properly.

This test doesn’t care about the database, the API, or the user interface it just cares about whether your calculateTotal(cartItems) function works.

Key Points for Good Unit Tests

Keep them isolated —no databases, APIs, or file systems.
Cover both happy paths and edge cases.
Make them small and fast so they can run frequently.

2. Integration Tests: Verifying Modules Work Together

Definition Integration tests focus on testing how different modules, services, or components interact with each other. Unlike unit tests, they don’t isolate a single function they simulate realistic flows between parts of the system.

Why they matter

Many bugs don’t occur in isolation but at the boundaries where systems communicate.
They help ensure that your code modules, services, or APIs play well together.
They give a higher level of confidence than unit tests but at a higher cost (slower, more complex).

Example Scenario In the shopping cart system, an integration test might check that:

When an item is added to the cart, it’s saved in the database.
The updated cart total is correctly retrieved via the API.
A discount applied in the service layer reflects in the final invoice.

This test involves the database, service logic, and possibly the API layer.

Key Points for Good Integration Tests

Focus on real-world workflows , not individual functions.
Use test doubles (e.g., mocks, stubs, in-memory databases) where necessary to keep them manageable.
Balance depth—don’t turn every integration test into a full E2E test.

3. End-to-End (E2E) Tests: Testing Like a User

Definition End-to-End tests validate the entire system from the user’s perspective. They simulate how a real user would interact with your application, covering everything from the front-end UI to the backend services and the database.

Why they matter

They catch issues that unit or integration tests miss.
They ensure the entire flow works in production-like conditions.
They give the highest level of confidence before release.

Example Scenario For the shopping cart system, an E2E test might:

Open the application in a browser.
Log in as a user.
Add an item to the cart.
Apply a discount code.
Proceed to checkout and ensure the final invoice matches expectations.

This test validates everything: frontend, backend, authentication, database, and even third-party services.

Key Points for Good E2E Tests

Keep them focused on critical user flows (checkout, login, payments).
Minimize their number since they are slow and costly to maintain.
Automate them in CI/CD but run them strategically (e.g., nightly builds, pre-release checks).

The Testing Pyramid: How They Work Together

Think of these tests as layers in a pyramid:

Unit tests form the base (most numerous, fastest).
Integration tests form the middle (fewer, slower).
E2E tests form the top (the least, but most comprehensive).

This balance ensures:

You catch bugs early with unit tests.
You validate real-world interactions with integration tests.
You simulate user behavior with E2E tests.

Best Practices Across All Test Types

Write clear, meaningful test names (e.g., should_apply_discount_when_valid_code_provided).
Aim for coverage, not 100% coverage obsession —focus on meaningful tests.
Automate tests in CI/CD pipelines for consistent feedback.
Keep tests deterministic —they should pass or fail for the same reason every time.
Continuously refactor tests just as you refactor code.

Final Thoughts

Good testing is about balance. Unit tests give you speed, integration tests give you realism, and E2E tests give you confidence from a user’s perspective. Together, they help you ship reliable software faster and with less stress.

This article is the first in a testing series where we’ll dive deeper into each type, exploring practical strategies, pitfalls to avoid, and real-world examples.

In the next article, we’ll break down Unit Testing in depth covering patterns, anti-patterns, and practical tips for writing effective unit tests.

How to Build Scalable Backend Systems with Python, C#, PHP and Dart

Billy Okeyo — Mon, 18 Aug 2025 00:00:00 +0000

Building scalable backend systems is one of the biggest challenges for developers today. As applications grow, so does the demand for performance, reliability, and maintainability. Whether you’re building a SaaS product, an e-commerce platform, or a real-time chat application, scalability can make or break your system.

In this article, we’ll explore how to build scalable backend systems using Python, C#, PHP, and Dart. We’ll look at architectural principles, performance tips, and practical examples in each language.

What Do We Mean by “Scalable Backend”?

A scalable backend system is one that can handle increasing load (users, requests, or data) without major rewrites or performance bottlenecks. Scalability comes in two main flavors:

Vertical Scaling (Scale Up): Adding more CPU, RAM, or resources to a single server.
Horizontal Scaling (Scale Out): Adding more servers or instances to distribute the load.

The best backends are built with scalability in mind from day one : modular, stateless, well-monitored, and optimized for both growth and resilience.

Core Principles of Scalable Backend Design

No matter the language, scalable systems share some common patterns:

Stateless Services → Each request should be independent. Store session data in Redis or a DB, not in memory.
Microservices Architecture → Break a monolithic app into smaller, independent services.
Load Balancing → Distribute requests evenly across multiple servers (NGINX, HAProxy, AWS ELB).
Caching → Use Redis, Memcached, or CDNs to reduce database load.
Database Scalability → Sharding, replication, and read-write separation.
Asynchronous Processing → Offload long tasks to queues (RabbitMQ, Kafka, Celery, Hangfire).
Monitoring & Logging → Use Prometheus, ELK stack, or Grafana for insights.

Python: Flexibility and Rapid Development

Python is loved for its developer-friendly syntax and rich ecosystem. While not the fastest language, Python excels when paired with the right tools.

Python Stack for Scalable Backends

Frameworks: Django (monolithic but battle-tested), FastAPI (modern and async-friendly), Flask (lightweight).
Async Support: asyncio, uvicorn, gunicorn for concurrent request handling.
Task Queues: Celery + Redis for background jobs.

Example: Async Endpoint with FastAPI

from fastapi import FastAPI
import httpx

app = FastAPI()

@app.get("/users")
async def get_users():
    async with httpx.AsyncClient() as client:
        response = await client.get("https://jsonplaceholder.typicode.com/users")
    return response.json()

This async API can handle thousands of concurrent requests without blocking.

C#: Enterprise-Grade Performance

C# with .NET Core is a powerhouse for scalable, enterprise-grade systems. It’s fast, strongly typed, and built for concurrency.

C# Stack for Scalability

Framework: ASP.NET Core (cross-platform, high-performance).
Async Support: Built-in async/await.
Background Jobs: Hangfire, Azure Functions, or MassTransit.
Deployment: Docker + Kubernetes, Azure App Service.

Example: Async API in ASP.NET Core

[ApiController]
[Route("api/[controller]")]
public class UsersController : ControllerBase
{
    private readonly HttpClient _client;

    public UsersController(HttpClient client)
    {
        _client = client;
    }

    [HttpGet]
    public async Task<IActionResult> GetUsers()
    {
        var response = await _client.GetStringAsync("https://jsonplaceholder.typicode.com/users");
        return Ok(response);
    }
}

With built-in dependency injection and async/await, ASP.NET Core scales smoothly in production.

PHP: Still Relevant and Scalable

Many dismiss PHP as “legacy,” but with modern frameworks and PHP 8 , it’s extremely fast and widely deployed.

PHP Stack for Scalability

Frameworks: Laravel, Symfony.
Async Support: Swoole or ReactPHP for non-blocking I/O.
Queues: Laravel Horizon, RabbitMQ, Redis.
Deployment: NGINX + PHP-FPM, Docker, or AWS Lambda (Bref).

Example: Scalable API with Laravel

Route::get('/users', function () {
    return Http::get("https://jsonplaceholder.typicode.com/users")->json();
});

Add Redis caching and Laravel Horizon to process jobs, and PHP apps scale to millions of requests per day.

Dart: The New Player for Backend Development

Dart is best known for Flutter mobile apps , but with Dart Frog and Shelf , it’s emerging as a backend option. Its async-first nature makes it perfect for scalable APIs.

Dart Stack for Scalability

Frameworks: Shelf, Dart Frog.
Async I/O: Built-in async/await.
Deployment: Docker + Kubernetes, Firebase Functions.

Example: Simple Dart Shelf API

import 'dart:io';
import 'package:shelf/shelf.dart';
import 'package:shelf/shelf_io.dart' as io;

void main() async {
  var handler = const Pipeline()
      .addMiddleware(logRequests())
      .addHandler((Request req) {
        return Response.ok('Hello, scalable world!');
      });

  var server = await io.serve(handler, InternetAddress.anyIPv4, 8080);
  print('Server running on http://${server.address.host}:${server.port}');
}

Dart’s async model is similar to Node.js, but with strong typing and better performance consistency.

Comparing the Four Languages

Language	Strengths	Best Use Cases
Python	Fast prototyping, AI/ML integration, async APIs (FastAPI)	Data-heavy apps, startups
C#	Enterprise-grade, high performance, async-first	Large-scale enterprise apps, fintech
PHP	Huge ecosystem, Laravel magic, easy deployment	E-commerce, CMS, SaaS
Dart	Async-first, integrates with Flutter, growing ecosystem	Mobile-first apps, experimental backends

Best Practices for Scaling Backends (Any Language)

Use APM tools (Datadog, New Relic) for performance monitoring.
Implement circuit breakers (Hystrix pattern) to prevent cascading failures.
Automate CI/CD pipelines for smooth deployments.
Prefer event-driven architecture for real-time scalability.
Benchmark with load testing tools (k6, JMeter, Locust).

Final Thoughts

Building a scalable backend isn’t about picking the “best” language—it’s about designing with scalability principles in mind.

Python gives you flexibility and speed of development.
C# delivers enterprise stability and blazing performance.
PHP remains a battle-tested workhorse with a huge ecosystem.
Dart offers exciting opportunities for mobile-first backends.

The key takeaway: Focus on architecture first, language second.

Top 10 Developer Excuses When Code Breaks (And What Actually Went Wrong)

Billy Okeyo — Mon, 04 Aug 2025 00:00:00 +0000

Let’s face it, as developers, we’ve all written code that breaks. Sometimes spectacularly. And when it does, our first instinct isn’t always to debug. No, first we reach for our arsenal of excuses.

In the spirit of honesty (and humor), here are the top 10 excuses developers give when things go wrong… and the real reasons behind the chaos.

10. “It Works on My Machine”

Translation: I’m not sure what you did, but it’s definitely not my fault.

Example:

You ship an Angular app. QA opens it and boom, blank screen. You shrug, “Works fine here.”

What Actually Went Wrong:

You forgot to add an environment variable or dependency to the Docker image / .env file. Your local machine has cached credentials, but the build pipeline does not.

Takeaway:

Test like a stranger using your code for the first time. Use clean environments or CI/CD staging builds for validation.

9. “Must Be a Browser Issue”

Translation: This browser has personally offended me. Let’s blame it.

Example:

The UI looks broken in Safari. Elements are overlapping and styles are ignored.

What Actually Went Wrong:

You used flex-gap, which Safari only started supporting in version 14+. Or maybe forgot a vendor prefix.

Takeaway:

Check compatibility on Can I use, use consistent CSS resets, and test on actual target browsers (even the cursed ones).

8. “The API Must Be Down”

Translation: It’s probably the backend’s fault. I’m just the messenger.

Example:

Your frontend app shows a spinning loader indefinitely. You hit refresh. Nothing.

What Actually Went Wrong:

The API is returning a 500 because you passed undefined as a required field. The API is up it’s just angry.

Takeaway:

Always log and inspect request/response payloads. Use tools like Postman or browser dev tools for quick sanity checks.

7. “I Swear I Didn’t Touch That Part of the Code”

Translation: The butterfly effect is real in software.

Example:

You update a CSS class name in one component. Suddenly another modal stops working.

What Actually Went Wrong:

You renamed a shared utility class or global style, assuming it was only used in your component.

Takeaway:

When working in shared codebases, assume nothing is isolated unless it explicitly is. Use scoped styles, modular patterns, and unit tests.

6. “It’s a Caching Issue”

Translation: I don’t know what’s wrong, but clearing cache usually helps.

Example:

The client swears they can’t see the latest changes, even though you deployed 10 minutes ago.

What Actually Went Wrong:

Your app uses aggressive service worker caching. Or your CDN is serving stale assets. Or your index.html has a hardcoded version number.

Takeaway:

Implement cache busting with hashed filenames. Understand how service workers behave. Sometimes a “clear site data” is a necessary evil.

5. “That Bug Was Already There”

Translation: Blame it on the ancestors.

Example:

User form validations are broken. You’re asked why.

What Actually Went Wrong:

Yes, the bug was technically there but your new field exposed it by breaking the logic inside a 4-year-old legacy function called handleEverything().

Takeaway:

Own the outcome, even if you didn’t write the original mess. Codebases are like archaeology you dig, you learn, you patch.

4. “That’s Just a Warning, Not an Error”

Translation: If the app compiles, it deploys.

Example:

Console is full of red text. You say, “Don’t worry, those are just warnings.”

What Actually Went Wrong:

The warnings were about deprecations, type mismatches, and possible memory leaks. Then something actually breaks because of them.

Takeaway:

Treat warnings like early indicators of future bugs. Don’t ship apps with noisy logs, they’re code smells.

3. “It’s Just a One-Line Change”

Translation: I didn’t test it, but how bad could it be?

Example:

You change one variable name to “improve clarity.” The app crashes.

What Actually Went Wrong:

That “one line” was imported across 14 files, passed through a state manager, and controlled a database flag.

Takeaway:

There is no such thing as a truly isolated one-line change. Always test after even the smallest commits.

2. “Git Must’ve Messed It Up”

Translation: Blame the tool everyone uses.

Example:

The build fails, files are missing, or changes look wrong. “It’s Git,” you say.

What Actually Went Wrong:

You force-pushed without pulling. Or committed to the wrong branch. Or resolved a merge conflict by deleting someone else’s work.

Takeaway:

Git is powerful and dangerous. Treat it with respect. Use clear commit messages, review diffs, and never git push --force without understanding the consequences.

1. “It Was Working Yesterday”

Translation: Time is a flat circle, and I’m confused.

Example:

The entire app crashes on startup. “But I didn’t touch anything!” you insist.

What Actually Went Wrong:

A dependency auto-updated overnight, your API key expired, or a cron job you forgot existed ran a destructive query.

Takeaway:

Software doesn’t exist in a vacuum. Track changes. Pin versions. Log everything. And accept that “yesterday” is a lie in the land of code.

Bonus Excuse: “It’s a Feature, Not a Bug”

Translation: I’m too tired to fix this. Let’s pretend it was intentional.

Final Thoughts

We’ve all used these excuses and honestly, sometimes they are valid. But the difference between a seasoned dev and a junior isn’t whether things break, it’s how quickly and responsibly we debug them.

So next time your app misbehaves, take a deep breath, open your logs, and maybe just maybe resist the urge to blame Safari.

Over to You:

What’s the wildest excuse you’ve heard (or used) when code broke? Tag me on LinkedIn or Twitter.

Diving into WebAssembly: What It Is and Why It Matters

Billy Okeyo — Wed, 23 Jul 2025 00:00:00 +0000

The web development landscape is evolving rapidly, and one of the most exciting advancements in recent years is WebAssembly (Wasm). Promising near-native performance in the browser, WebAssembly is changing how we think about web applications, enabling new use cases that were previously difficult or impossible to achieve with JavaScript alone.

But what exactly is WebAssembly, why does it matter, and how does it fit into modern web development? Let’s explore.

What Is WebAssembly?

WebAssembly is a binary instruction format designed as a portable compilation target for high-level languages like C, C++, Rust, and Go. It allows developers to run code in the browser at speeds close to native performance , making it ideal for compute-intensive tasks.

Unlike JavaScript, which is interpreted or JIT-compiled at runtime, WebAssembly is pre-compiled , meaning the browser can execute it much faster. It runs in the same sandboxed environment as JavaScript and integrates seamlessly with existing web APIs.

Key Features of WebAssembly:

Fast execution – Near-native performance in the browser.

Portable – Runs across different platforms and architectures.

Secure – Executes in a sandboxed environment, just like JavaScript.

Language-agnostic – Can be compiled from multiple languages.

Interoperable – Works alongside JavaScript, allowing gradual adoption.

Why Does WebAssembly Matter?

1. Performance-Critical Applications

JavaScript is highly optimized, but it still can’t match the raw performance of compiled languages for tasks like:

Game engines (Unity, Unreal Engine)
Video/audio editing (FFmpeg compiled to Wasm)
Scientific computing & simulations

2. Running Legacy Code on the Web

Many applications written in C, C++, or Rust can now be ported to the web without a full rewrite. Examples include:

AutoCAD (using WebAssembly for CAD tools)
Photoshop (ported to the browser with Wasm acceleration)

3. Blockchain & Decentralized Apps (DApps)

WebAssembly is a key component of blockchain platforms like:

Ethereum 2.0 (executing smart contracts via Wasm)
Polkadot & Cosmos (using Wasm for runtime modules)

4. Serverless & Edge Computing

With WASI (WebAssembly System Interface), Wasm can run outside the browser, enabling:

Fast serverless functions (Cloudflare Workers, Fastly Compute@Edge)
Plugin systems (e.g., Envoy proxies using Wasm for extensions)

5. Augmented & Virtual Reality (AR/VR)

High-performance 3D rendering in the browser (via WebGL + Wasm) makes WebAssembly a strong candidate for immersive web experiences.

How WebAssembly Fits into Modern Web Development

WebAssembly does not replace JavaScript —it complements it. Here’s how they work together:

Use Case	JavaScript’s Role	WebAssembly’s Role
DOM Manipulation	Best choice	Not suitable
High-performance computing	Possible, but slower	Ideal for heavy computations
Cross-platform apps	Works but may lack speed	Near-native performance
Legacy code on the web	Difficult to port	Easier to compile & run

Adoption in Major Platforms

Google Earth (uses Wasm for smooth rendering)
Figma (relies on Wasm for performance-critical design tools)
Amazon Prime Video (improved streaming performance with Wasm)

The Future of WebAssembly

WebAssembly is still evolving, with exciting developments on the horizon:

WASI (WebAssembly System Interface) – Running Wasm outside browsers.
Threads & SIMD support – Better parallelism for multi-core processing.
Garbage Collection (GC) proposal – Easier integration with managed languages (Java, C#).
WebAssembly Components – Modular, reusable Wasm modules.

As more browsers and platforms adopt WebAssembly, we can expect even broader use cases, from AI inference in the browser to fully portable cloud functions.

Conclusion

WebAssembly is a game-changer for web development, unlocking performance levels previously reserved for native applications. While JavaScript remains the backbone of the web, Wasm provides a powerful tool for performance-critical tasks, legacy code porting, and new computing paradigms.

Whether you’re building high-performance web apps, exploring blockchain, or optimizing serverless functions, WebAssembly is worth keeping an eye on—it’s not just the future; it’s already here.

Ready to dive in? Check out the WebAssembly official site or experiment with compiling your first Wasm module via Emscripten or Rust’s wasm-pack.

Building for Speed: Best Practices for Optimizing Your Web App

Billy Okeyo — Mon, 07 Jul 2025 00:00:00 +0000

In today’s fast-paced digital world, performance is a critical factor in user experience, SEO rankings, and conversion rates. A slow-loading web app can frustrate users, increase bounce rates, and hurt your business.

The good news? There are proven optimization techniques to make your web app blazing fast. From lazy loading and caching strategies to reducing JavaScript bloat , this guide covers practical, actionable tips to speed up your web app in all scenarios.

1. Optimize Asset Delivery

Use Efficient Image Formats

Convert images to WebP (25-35% smaller than JPEG/PNG).
Use responsive images with <picture> and srcset.
Compress images with tools like Squoosh, TinyPNG, or ImageOptim.

Lazy Load Non-Critical Resources

Defer offscreen images & iframes with loading="lazy":

<img src="image.jpg" loading="lazy" alt="...">
<iframe src="video.html" loading="lazy"></iframe>

Use Intersection Observer API for dynamic content.

Serve Modern Code (ES6+) with Fallbacks

Use module/nomodule pattern for differential loading:

<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js"></script>

Transpile only what’s needed (avoid polyfilling for modern browsers).

2. Reduce JavaScript Bloat

Code Splitting & Dynamic Imports

Split bundles by route (React: React.lazy, Vue: defineAsyncComponent).
Load non-critical JS on demand:

import('./module.js').then(module => module.init());

Tree Shaking & Dead Code Elimination

Use ES6 modules (import/export) for better static analysis.
Enable Webpack/Rollup’s tree-shaking (remove unused exports).

Minimize Third-Party Scripts

Audit dependencies with:

npx source-map-explorer bundle.js

Load non-essential scripts (analytics, ads) after page load.

3. Leverage Caching Strategies

HTTP Caching (Cache-Control Headers)

Cache static assets aggressively:

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

Use versioned filenames (main.abcd1234.js) for cache busting.

Service Workers for Offline Support

Cache critical assets with Workbox :

import {precacheAndRoute} from 'workbox-precaching';
precacheAndRoute(self.__WB_MANIFEST);

CDN for Global Performance

Serve assets from edge locations (Cloudflare, AWS CloudFront, Fastly).

4. Optimize Rendering Performance

Reduce Critical Rendering Path

Inline critical CSS & defer non-critical styles:

<link rel="stylesheet" href="non-critical.css" media="print" onload="this.media='all'">

Minimize render-blocking JavaScript (async, defer).

Optimize CSS & Avoid Layout Thrashing

Use CSS containment (contain: layout paint;) for isolated components.
Avoid forced synchronous layouts (batch DOM reads/writes).

Virtualize Long Lists

Use React Window, Vue Virtual Scroller for large datasets.

5. Network & Server-Side Optimizations

Enable Compression (Brotli > Gzip)

Configure Brotli on your server:

brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript;

HTTP/2 & HTTP/3 (QUIC)

Multiplexing reduces latency (no more domain sharding needed).
Server push preloads critical assets.

Reduce TTFB (Time to First Byte)

Optimize backend queries (database indexing, caching).
Use edge functions (Cloudflare Workers, Vercel Edge Functions).

6. Monitor & Continuously Improve

Measure Performance Metrics

Core Web Vitals (LCP, FID, CLS) via Google Lighthouse.
Real User Monitoring (RUM) with CrUX, New Relic, Sentry.

A/B Test Optimizations

Compare before/after using WebPageTest, GTmetrix.

Adopt a Performance Budget

Example budget:

{
  "js": "150kb",
  "css": "50kb",
  "images": "1mb",
  "fonts": "100kb"
}

Final Thoughts

Optimizing web app speed is not a one-time task —it’s an ongoing process. By reducing JavaScript bloat, leveraging caching, lazy loading assets, and optimizing server responses , you can dramatically improve load times and user experience.

Start small, measure impact, and iterate. Your users (and search rankings) will thank you!