Great work!

XP to next level

BugEater

The Developer's Top Logic Mistakes

Learning Objectives

By the end of this lesson you will be able to:

  • Name and describe five of the most common developer logic mistakes
  • Translate each mistake into a targeted test case
  • Explain the subtle input values that consistently expose each mistake type

Mistake #1: Zero as Falsy

In JavaScript (and many other dynamically-typed languages), 0 evaluates to false in a boolean context. A developer writes:

if (quantity) {
  processOrder(quantity);
}

Intending: "if quantity is provided." But this silently skips orders with quantity = 0 (which should trigger a validation error, not silent rejection).

Test to catch it: Submit with quantity = 0. Observe if the system correctly shows a validation error or silently fails.

Mistake #2: Missing trim()

A developer validates that a field is non-empty:

if (name !== "") {
  accept();
} else {
  reject("Name is required");
}

A user types four spaces. " " !== "" is true. The spaces pass as a valid name.

Test to catch it: Enter a field value consisting only of whitespace (spaces, tabs). Should be rejected as empty.

Mistake #3: Off-by-One in Ranges

The specification says: "Discount applies for orders of 10 or more items."

The developer writes: if (quantity > 10). Orders of exactly 10 items don't get the discount.

Test to catch it: Submit with quantity = 10 (the exact boundary). Also test 9 (should fail) and 11 (should pass).

Mistake #4: Incorrect Math.abs()

A developer needs to validate that a temperature delta is within ±5 degrees. They write:

if (Math.abs(delta) < 5) { ... }

But they meant <= 5. Now a delta of exactly 5 or -5 is rejected.

More dangerously: some developers use Math.abs() to normalize negative inputs before applying a range check, forgetting that the normalized value changes the semantics.

Test to catch it: Submit values at the exact boundary: 5, -5, 4.9, -4.9. Each should behave correctly.

Mistake #5: AND Instead of OR in Validation

A form requires at least one of: email OR phone.

Developer writes: if (email && phone) { allow(); } — now both are required.

Test to catch it: Submit with email only (no phone). Submit with phone only (no email). Both should succeed.

Mistake #6: The Missing else Branch

A conditional chain handles "approved," "pending," and "rejected" — but a fourth status ("archived") is added later. The developer adds it to the database but forgets to add an else if branch. Now archived items trigger the "rejected" behavior.

Test to catch it: Always test every possible value of an enumerated field, even "unusual" ones. If the field is a status enum, test every possible status value — not just the happy-path ones.

Pro Tip: The sentinel test values 0, "", " " (space), and the exact boundary value (exactly 10 in a >10 range) are the fastest way to find bugs in any new form. They cost 30 seconds each and catch a disproportionate number of real defects.

Summary

These six mistake types — zero-as-falsy, missing trim, off-by-one, Math.abs() misuse, AND/OR confusion, and missing else branches — are the starting catalog for any serious tester's error guessing checklist. Each one translates directly to a test case that most scripted suites never include. In the next lesson, you'll build your own checklist structure to carry these forward.

Quiz

A developer uses > instead of >= for a boundary check. Which test input BEST detects this?

"Off-by-one" errors most commonly appear in:

A developer codes "user is either admin OR active for more than 30 days" using && instead of ||. Which user scenario exposes this bug?

Which common mistake causes a form field to accept a value it should reject with no error message?