Guided Build: Test, Fix, Polish

The Difference Between "It Works" and "It's Good"

After Sessions 1 and 2, you have a functional project. Congrats — that's a real accomplishment. But "it works on my computer when I use it carefully" is not the same as "it's good enough to share."

This session is about closing that gap. You'll systematically break your own project (on purpose), fix what you find, and polish the design until it looks intentional, not accidental.

Time required: 45–60 minutes. This is your last building session before deployment. After this, your project should be ready for real users.

Phase 1: Break It On Purpose (20 minutes)

The best way to find bugs is to use your project like someone who has never seen it before. Try everything that could go wrong.

Test 1: Empty Inputs

• Click "Add" without typing anything. Does it add a blank item? It shouldn't.
• Submit a form with missing fields. Does it give a helpful error or just break?
• Enter only spaces. Does your project treat that as valid input?

If any of these cause problems, use this prompt:

"Add input validation to my [add habit / data entry / contact] form. Prevent: (1) empty submissions, (2) whitespace-only submissions, (3) submissions with missing required fields. Show a helpful error message under the input field (red text, like 'Please enter a habit name'). Here's my current code: [paste the form section]."

Test 2: Extreme Inputs

• Enter a very long name (50+ characters). Does the layout break?
• Enter special characters: quotes, <script>, emojis, ampersands.
• For number fields: enter negative numbers, zero, very large numbers, letters.

If text overflows or the layout breaks:

"Long text is breaking my layout. When a user enters a name with 50+ characters, it [describe what happens — overflows the container, pushes other elements, etc.]. Add CSS to handle long text gracefully (overflow-wrap, text truncation, or max-width). Here's my current code: [paste the relevant CSS and HTML]."

Test 3: Mobile and Responsiveness

• Resize your browser to phone width (about 375px wide). Does everything still fit?
• Can you tap all the buttons easily? (They should be at least 44px tall for fingers.)
• Does text wrap properly or get cut off?
• If you have a sidebar or navigation, does it collapse or become a menu on mobile?

If your project doesn't work on mobile:

"Make my project mobile-responsive. When the screen is narrower than 600px: (1) stack any side-by-side elements vertically, (2) make buttons full-width and at least 44px tall, (3) increase font size to at least 16px so it's readable, (4) hide any non-essential elements. Here's my current code: [paste]. Focus on the [section that's breaking] first."

Test 4: Navigation and Flow

• Click every link and button. Does each one do what you expect?
• Can you get "lost" anywhere with no way to go back?
• If you have multiple pages, do all navigation links work?
• Does the back button in your browser work as expected?

Phase 2: Fix What You Found (15 minutes)

You've got a list of bugs. Now fix them — but follow these rules:

1. Fix one bug at a time. Don't try to fix everything at once. Make one change, test it, confirm it works, then move to the next bug. Changing five things at once makes it impossible to know what fixed what (or what broke something else).

2. Start with the worst bug. Which bug makes your project unusable or confusing? Fix that first. A visual glitch can wait; a button that doesn't work can't.

3. Save after each fix. Keep a working backup. If a fix breaks something worse, you can go back to the last working version instead of starting over.

4. Use AI for the hard ones. If a bug takes more than 10 minutes of staring at code, describe it to AI using the bug report pattern from Lesson 5.2: what you expected, what actually happens, what you've tried, and the relevant code.

Phase 3: Polish (15 minutes)

Your project works and the bugs are fixed. Now make it look like you meant it. Polish is the difference between a school assignment and something you'd actually show people.

Visual Consistency

• Is the same font used everywhere? (Pick one font for headings, one for body text, max.)
• Are colors consistent? Every button should be the same color. Every heading should be the same size.
• Is spacing even? Elements shouldn't be crammed together in one place and spread out in another.

Content Polish

• Are there any placeholder texts left? ("Lorem ipsum," "test," "asdfg," sample data you forgot to replace.)
• Do headings and labels clearly describe what they're for?
• Is there a clear title or header that tells visitors what this project is?

Professional Touches

• Add a favicon (the little icon in the browser tab). Ask AI: "Generate a simple favicon for a [project type] using an emoji or simple shape."
• Make sure the page title (what shows in the browser tab) is your project's real name, not "index.html."
• Add a small footer with your name or project name.

Use this all-in-one polish prompt:

"Review this code and suggest visual improvements to make it look more polished and professional. Focus on: consistent spacing, font sizes, color usage, hover effects on interactive elements, and smooth transitions. Don't change the functionality — just make it look better. Here's my code: [paste code]."

KEY CONCEPTS

KEY CONCEPTS — LESSON 5.5

1. Test systematically: empty inputs, extreme inputs, mobile, and navigation. Don't just test the "happy path."

2. Fix one bug at a time, starting with the most severe. Save after each fix.

3. Use AI for bugs that stump you — but always describe the problem clearly first.

4. Polish means visual consistency (fonts, colors, spacing), cleaning up placeholder content, and adding professional touches.

5. "Good enough to share" = it works, it looks intentional, and a new user can figure it out without your help.