Questions: Testing and Validation Basics

Question 1

A function `is_palindrome(s)` is tested with `assert is_palindrome('racecar') == True` and `assert is_palindrome('hello') == False`. Both tests pass. Which statement is most accurate?

• A. The function is correct — it handles the typical cases
• B. The tests are sufficient — one positive and one negative case is standard practice
• C. The tests are incomplete — they don't verify behavior on edge cases like empty strings, single characters, or strings with spaces
• D. The function is correct for all inputs since both assertions check true and false cases

Answer: (C)

Two tests covering a typical palindrome and a typical non-palindrome leave many behaviors unverified. What happens with an empty string? A single character? A string with spaces like 'a man a plan a canal panama'? These edge cases are where bugs most commonly hide — developers naturally think about typical inputs when writing code, so typical-case tests tend to pass even in buggy implementations. Tests only verify what they test; passing does not imply correctness for untested cases.

Question 2

A developer is told 'comprehensive testing slows down development.' Which response best reflects the insight from this topic?

• A. True — testing is valuable long-term but undeniably adds time in the short run
• B. False — well-designed tests make development faster by catching bugs at the moment of creation rather than in debugging sessions later
• C. True — testing should be reserved for production-ready code, not used during active development
• D. False — tests run automatically and add no time cost at all

Answer: (B)

Testing's time cost is at the point of writing tests; its time savings is at the point of finding and fixing bugs. Bugs found during development (when the relevant code is fresh in memory) are drastically cheaper to fix than bugs found in production (when you must reconstruct context, understand interactions, and often fix under pressure). A function with good tests is a reliable building block you can refactor or extend with confidence, because the tests will immediately tell you if you've broken something.

Question 3

If most tests in a test suite pass, the program is correct.

• T. True
• F. False

Answer: False

Tests only verify what they test. A test suite might pass with 100% success while missing entire categories of behavior: untested edge cases, race conditions, unexpected input types, interactions between modules. Passing tests mean 'the program behaves correctly in the specific situations these tests describe' — not 'the program is correct in all situations.' Testing can demonstrate the presence of bugs (a failing test is definitive) but cannot prove their absence.

Question 4

Writing tests before writing the implementation (test-driven development) can improve code quality because knowing you need to test a function encourages you to design it with cleaner inputs and outputs.

• T. True
• F. False

Answer: True

Testing changes how you write code, not just how you verify it. When you know you'll need to write a test that calls a function with specific inputs and checks the output, you naturally write the function to have clear, predictable interfaces. Functions with many side effects, global state dependencies, or tangled logic are hard to test, so TDD pressure tends to push code toward smaller scope, fewer side effects, and cleaner separation of concerns — a design improvement beyond the immediate bug-catching benefit.

Question 5

Why should test cases include edge cases and error cases in addition to normal cases, and where are bugs most commonly found?

Model answer: Edge cases and error cases test the boundaries and assumptions of the code rather than the typical path. Developers naturally think about typical inputs when writing code, so typical cases tend to work even in buggy implementations. The extremes — empty input, boundary values, invalid types, maximum sizes — are where implicit assumptions break. Bugs hide at edges because developers rarely imagined those paths; they hide in error handling because it is often written quickly after the main logic.

A function that adds two numbers might work correctly for add(2, 3) but fail on add(0, 0) if there's an accidental early-return check, or on very large numbers if there's an overflow issue, or on string inputs if there's no type guard. Normal cases give you false confidence; edge cases reveal what the code actually does versus what you assumed. The discipline of explicitly asking 'what is the smallest possible input? the largest? the empty case? the invalid case?' is what separates thorough testing from perfunctory testing.