Static vs Dynamic Testing
Not all testing requires running code. Static testing finds defects without executing software — reviewing requirements, code, and design documents. Dynamic testing runs the software. Understanding both is essential because static testing catches requirement flaws and code quality issues that dynamic testing cannot.
Static vs Dynamic
- Static Testing: Reviews and analysis WITHOUT running the code. Examples: requirements review, code review, static analysis, walkthroughs, inspections.
- Dynamic Testing: Executing the software and observing behavior. Examples: unit tests, integration tests, performance tests, manual testing.
- Key insight: 40-60% of all defects can be found through static testing BEFORE the code is even written.
- Static testing is cheapest — a review comment costs minutes to fix; a production bug costs weeks.
Static Testing Tools & Techniques
// ── STATIC ANALYSIS TOOLS (run without executing code) ────────
// ESLint catches code quality issues statically:
// Before: no-op reassignment would cause a bug
function calculateDiscount(price, percent) {
let result = price; // ESLint warning: 'result' is assigned but never used
result = price - (price * percent); // missing return
}
// ── MISSING RETURN — caught by static analysis before testing:
// TypeScript (static type checker) catches:
function getUser(id: number): User {
if (id > 0) {
return db.find(id);
}
// TypeScript error: Function lacks ending return statement
// and return type does not include 'undefined'
}
// ── REQUIREMENTS REVIEW (static testing of specifications) ─────
// Spec: "User must be able to log in with email and password"
// Static review questions:
// ❓ What happens if email is not registered?
// ❓ How many failed attempts before lockout?
// ❓ Does the spec cover forgot password flow?
// ❓ What are the password strength requirements?
// These questions catch requirement defects BEFORE development.
// ── DYNAMIC TESTING (executing the code) ──────────────────────
test("login returns 401 for unregistered email", async () => {
const res = await post("/login", { email: "unknown@test.com", password: "test" });
expect(res.status).toBe(401);
});
// This dynamic test verifies behavior at runtime.Common Mistakes
- Skipping code reviews — code review is static testing; skipping it means defects that a 5-minute review would catch reach the test cycle.
- Treating static analysis warnings as optional — linting rules exist because the warned patterns are known sources of bugs.
- Not reviewing test cases themselves — test cases can have bugs too! Review test cases before running them.
- Assuming code review replaces dynamic testing — static testing finds different defects from dynamic testing; both are required.
Tip
Tip
Practice Static vs Dynamic Testing in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task — (1) Write a working example of Static vs Dynamic Testing from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Quick Quiz
Common Mistake
Warning
A common mistake with Static vs Dynamic Testing is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Not all testing requires running code.
- Static Testing: Reviews and analysis WITHOUT running the code. Examples: requirements review, code review, static analysis, walkthroughs, inspections.
- Dynamic Testing: Executing the software and observing behavior. Examples: unit tests, integration tests, performance tests, manual testing.
- Key insight: 40-60% of all defects can be found through static testing BEFORE the code is even written.