Test Distribution – The need for Customization
Test Distribution – The need for Customization
When we build and test an application, we know it must go through multiple testing levels:
Unit, Component Integration, End-to-End (E2E), and Exploratory testing.
But have you ever paused to ask:
Which levels should be dense in test coverage? And where can we be lighter?
The answer, in my experience, depends on the context — the nature of the application.
Understanding the Scope of Test Levels
Before diving into test distribution models, it’s important to understand what each level is responsible for:
Unit Tests:
Focus on small, isolated units of code such as individual functions or classes. They are fast, provide quick feedback, and are usually written and maintained by developers.Component Integration Tests:
In Backend, these validate interactions between connected modules or services — e.g., how an api endpoint work of its own with in the microservice, not covering the processes between other microservices. In Client side of apps, these specifically test how UI components interact within the user interface. This includes validating things like event handling, data flow through props/state, rendering logic, and boundary behavior between components. These are vital for React, Angular, or other component-based frameworks where functionality often emerges from composition.End-to-End (E2E) Tests:
Simulate real user scenarios by interacting with the application from the UI down through backend services or API e2e testing in a test environment. These tests cover full workflows like login, checkout, or user onboarding.Exploratory Testing:
Involves manual, unscripted testing to identify unexpected behaviors, usability concerns, or gaps missed by automation. This usually gathers more information about the application.
1. Fresh Startup Applications
For a fresh app of a startup, recently entered the market with a small set of users, here’s what works well:
- A solid foundation of unit tests
- Strategic end-to-end tests for core flows
- Emphasis on exploratory testing to catch unexpected issues
This is where the hourglass model of test distribution fits:
Startups often deal with rapid changes in the features and a limited user base. The priority is speed and flexibility — E2E tests alone won’t be sufficient, but too much testing in the middle layer may need a lot of changes frequently.
If there’s time and bandwidth, broader coverage is welcome — but start lean and intentional.
2. Scaling Applications
As an application grows, so does:
- The user base
- The complexity
- The need for stability
For scaling apps, it’s important to add more structure in the middle layers, especially Component Integration testing.
This is where the classic testing pyramid becomes valuable:
- Dense unit tests at the base
- A moderate number of component integration tests in the middle
- A smaller number of E2E tests at the top which cover the processes of the application
This model balances speed, granularity, and reliability as the application becomes more feature-rich and change-prone. There are more models of test distribution which can be tried, but that will be covered in another blog. Also, the scaled up application.
How do you distribute tests across your product lifecycle?
- Do you follow a testing pyramid, hourglass, or another model?
- How do you balance unit, integration, E2E, and exploratory tests in your team?
I’d love to hear your approaches and any lessons you’ve learned in evolving your test distribution strategy. Let’s learn from each other!