Think of tests as small promises

A useful test is a promise about behavior. It should fail when that promise is broken and stay quiet when implementation details change.

Use this post as a small study note for making better decisions while solving, not as a quick definition dump. Read the idea, pause at the example and try to move one line forward yourself, then use the checklist on a real problem.

The main idea

Start with one normal case, one edge case, and one failure case. Name each test in plain language.

The important part is not memorizing the method; it is noticing what calls the method into action. Which expression, diagram, unit, variable, or code behavior made this approach the right one? If you can name that trigger, a similar problem becomes much less stressful.

A short example

For a discount function, test a regular price, a zero discount, and an invalid negative price.

How to approach it step by step

1. Write the givens cleanly and fix units, symbols, or variable names before calculating.
2. Identify the intermediate fact you need before trying to jump directly to the answer.
3. After each line, run a small check: do the units match, is the sign correct, is indentation or scope correct in code?
4. When you get an answer, return to the original question and check that it answers exactly what was asked.

Check while you solve

• Test behavior, not private implementation.
• Use examples a human can read.
• Add a regression test when you fix a bug.

The common mistake

A test that reads like a sentence is easier to trust six months later.

The practical way to catch this mistake is to check the decision points, not only the final answer. Ask questions like: Why this formula? Why this component? Why this loop condition? That makes the answer stronger in content, not just in arithmetic.