Validate Boundaries and Test Pure Functions

Write the contract first

A function contract describes acceptable inputs, the result and failures. For this example, a quantity must be a finite non-negative number and price must be finite and non-negative. Decide whether fractional quantities are allowed before implementing. Validation rules are part of the product, not an afterthought.

Reject ambiguous input

Number.isFinite checks that a value is a number with a finite value. It does not coerce text into a number. This helps distinguish validation from conversion. If you accept user text, parse it deliberately at the application boundary and handle empty text separately instead of silently turning it into zero.

Test more than a happy path

A useful test set includes an ordinary order, zero quantity and an invalid negative price. Name the expected behavior for each case. A test that repeats the exact implementation without independent examples can preserve the same mistake. Test the contract rather than incidental formatting.

Read errors as part of the result

Throwing an error makes a failed contract explicit. The caller should show a clear message and keep the person’s input so it can be corrected. A production application also needs appropriate server validation. A client-side disabled button does not prevent a crafted request.

Project checkpoint

Finish the quotation project by separating input parsing, validation, calculation and display. Write a README with supported units, rounding assumptions and unsupported cases. Include tests and one reproducible example. That evidence is more useful than claiming the project is production-ready because the first screen looks complete.

Read the example

function total(price, quantity) {
  if (!Number.isFinite(price) || !Number.isFinite(quantity) || price < 0 || quantity < 0) {
    throw new Error("Use finite, non-negative numbers");
  }
  return price * quantity;
}
console.log(total(12, 3));
console.assert(total(12, 0) === 0, "Zero quantity");

Line-by-line explanation

1. The condition checks both values before multiplication.
2. throw stops an invalid calculation.
3. The assertion checks the zero-quantity boundary.

Expected output

36

Common mistakes to avoid

• Treating client-side checks as authorization
• Silently coercing an empty string to zero
• Testing only one ordinary input

Summary & next step

• Can you now reject invalid numeric input?
• Can you now test normal and boundary cases?
• Can you now keep business rules explicit?

Complete the exercise and pass the knowledge check to complete this lesson. Guest progress stays on this browser and does not sync across devices.

Related BizAIPro tools