Testing as You Go

Building without testing is like assembling furniture without checking that each piece connects before moving to the next. You end up with a finished-looking object that wobbles and falls apart the moment someone actually uses it. Testing as you go is not extra work — it is how you avoid doing all the work twice.

What Testing Means for a Builder Like You

Testing in professional software development is a field of its own, with formal tools and methodologies. For your first projects, you do not need any of that. You need two habits. Habit 1 — Test the feature you just added before doing anything else. Every time you add something, try to break it. Click the button twice. Type a letter where a number is expected. Leave a field empty. Try it on your phone if the project runs in a browser. If it survives your attempts to break it, it probably works. Habit 2 — Test the things you touched last time, not just the new thing. When you change code to add a feature, you might accidentally change how an old feature behaves. This is called a regression. Spend thirty seconds clicking through the features you built previously after every new addition.

Let us watch Priya test her quiz app after adding the wrong-answer highlight feature. She does not just check that wrong answers turn red. She also checks: - Do correct answers still turn green? (They should — she did not change that.) - Does the Next button still appear after answering? (It should.) - Does the score counter still increment correctly? (It should.) - What if she clicks two answers quickly before the Next button appears? (New potential bug.) She found a regression: the score counter was double-incrementing when she clicked very fast. She had not changed the score counter — but the new highlighting code ran on every click, including rapid ones. Catching this immediately, right after adding the highlighting feature, meant the fix took five minutes. Catching it a week later, after adding five more features, would have been much harder.

Writing a Test Checklist

A test checklist is a written list of things to check after every change. You write it once, early in the project, and add to it each time you add a feature. For Marcus's reading tracker, the test checklist after three features looked like this: - Can I type a number and click Log it? Entry appears in list. [check] - Can I delete an entry? It disappears from the list. [check] - Does the weekly total update when I add or delete an entry? [check] - What if I type a letter instead of a number? Error message appears. [check] - What if I type nothing? Error message appears, not an empty entry. [check] Every time he adds a feature, he runs through the whole checklist. It takes about two minutes. It catches regressions before they become invisible landmines buried under new code.

Describing Bugs to AI Clearly

When your testing reveals a bug, the quality of your bug description determines how fast it gets fixed. A bug report has three parts: 1. What you did — the exact steps you took. 2. What you expected — what should have happened. 3. What actually happened — what did happen instead. Example of a poor bug report: 'The delete button is broken.' Example of a good bug report: 'Steps: I added three entries, then clicked the delete button on the second entry. Expected: the second entry disappears and the first and third remain. Actual: all three entries disappeared.' The good report tells the AI exactly what is happening and gives it enough information to find the root cause. The poor report forces the AI to guess, which wastes your time.