An edge case is an unusual or boundary input that may expose behavior different from the regular case. Treating it explicitly makes software behavior—and its failures—easier to understand. section 9.3
Weight conversion
A pounds-to-kilograms converter tests three distinct outcomes: converting 10 pounds, returning zero for 0 pounds, and rejecting −5 pounds with an IllegalArgumentException. The zero value is the edge case; the negative value is an invalid-input or exception case. section 9.3
Use edge cases to make expected behavior concrete:
- Test one behavior at a time and name the condition and expected result. section 9.3
- Cover normal success, boundary values, invalid inputs, and other expected failures without duplicating test logic. section 9.3
Table 9.3 Main types of tests
|
Type of test
|
Purpose / Description
|
Common Frameworks / Tools
|
|---|---|---|
|
Unit tests
|
Verify the smallest pieces of code (methods and functions) in isolation. They are fully automated, run locally, and in CI/CD pipelines.
|
Java: JUnit, TestNG Python: PyTest, unittest JavaScript: Jest, Mocha, Jasmine C#:/.NET: xUnit, NUnit, MSTest
|
|
Integration tests
|
Validate how modules or services interact. They are mostly automated, run locally, and in CI/CD pipelines.
|
Java: Spring Test, Arquillian Python: PyTest + fixtures JavaScript: SuperTest, Cypress .NET: MSTest, SpecFlow
|
|
Functional tests
|
Test complete business scenarios from a user’s point of view. They are manual or automated.
|
Selenium, Cypress, Playwright, Robot Framework
|
|
Acceptance tests
|
Verify that newly delivered features meet client requirements. They are manual or automated.
|
Multilanguage: Cucumber (Gherkin) Python: Behave NET: Reqnroll
|
|
Regression tests
|
Essential tests run after changes to ensure nothing broke. They can be automated or manual and typically replay key unit, integration, acceptance, and functional tests to confirm stability after updates.
|
Uses the same tools as unit, integration, acceptance, and functional tests.
|
|
Performance tests
|
Performance tests measure speed, response time, scalability, and resource usage using load, stress, or endurance testing. They are usually fully automated but not included in the regular CI/CD pipeline.
|
JMeter, Gatling, Locust, k6, Artillery
|
|
Security tests
|
Detect vulnerabilities such as injections, XSS, or weak authentication. Automated through static code analysis tools, such as SonarQube, and dynamic testing tools, often complemented by manual penetration testing.
|
OWASP ZAP, Burp Suite, Snyk, Bandit
|
|
Chaos engineering/resilience testing
|
Intentionally inject failures or adverse conditions to verify that the system remains stable and recovers as expected under real-world turbulence. Manual or automated, but used selectively in staging or carefully controlled production environments.
|
Chaos Mesh, LitmusChaos
|
|
Accessibility tests
|
Ensure compliance with accessibility standards. Automated and manual tools detect violations, and testers confirm usability.
|
Axe, Lighthouse, Pa11y, Deque tools
|
|
Exploratory tests
|
Manual tests. Discover UX flaws or unexpected behavior. Rely on tester observation and creative exploration.
|
Compare unit tests with integration, functional, and acceptance tests when deciding where an edge condition belongs. section 9.3
