Confirmation bias makes developers notice evidence that supports their beliefs while overlooking contrary evidence. Testing counters it by turning doubt into deliberate verification and exposing weak spots. section 9.3
Use testing to make doubt practical:
- Test expected successes, boundary values, and failures instead of checking only what should work. section 9.3
- Choose complementary test levels because unit, integration, functional, and acceptance tests reveal different problems. section 9.3
A small test suite that challenges assumptions
For a poundsToKilos conversion, test a normal value, zero, and a negative input that must throw an exception. The suite checks both the expected path and an assumption-breaking boundary.
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 testing levels, purposes, and tools when selecting evidence that can challenge a software assumption. section 9.3
