Lesson 7: Polish, Testing & External API Integration

Welcome to Week 5! You’ve built the core of your Community Hub. Now it’s time to take it from functional to polished. This week is all about improving the quality of your code, making sure it works as expected, and adding a fun integration with an external API.

🎯 Learning objectives

Understand the importance of code quality and how to use AI to refactor and improve your code.
Learn the basics of testing and how to write simple tests for your components.
Learn how to integrate a third-party API into your application.

1. What is code quality (and why does it matter)? 💎

You’ve been reviewing your code before every commit since Lesson 5: checking that it works, that you understand it, and that it matches your ticket. Now we’re going a step further. Instead of just asking “does it work?” we’re asking “is this the best version of this code?”

Code quality is a measure of how good your code is. Is it easy to read? Is it efficient? Is it easy to change without breaking things? High-quality code is a gift to your future self and to your teammates.

AI as your code review partner: You can use Codex to act as a code reviewer. Paste a snippet of your code and ask:

"Can you refactor this code to be more readable?"
"Is there a more efficient way to write this function?"
"Can you add comments to this code to explain what it does?"

✅ Exercise 1: Refactor with AI

Find a component you wrote in a previous week.
Paste the code into Codex and ask it to refactor the code for readability.
Review the changes. Do you agree with them? Why or why not?

2. Intro to testing 🧪

How do you know your code works? You test it! Testing is the process of checking that your code does what you expect it to do.

In software development, there are three main levels of testing:

Unit tests check one piece in isolation: does this function return the right value? Does this component render correctly?
Integration tests check that pieces work together: does the form submit to the API and save to the database?
End-to-end (E2E) tests check the whole app like a real user: can someone log in, create a post, and see it appear on the page?

You’ll also hear a few other terms in the wild:

Smoke tests are the most basic “does the app even start up?” check.
Regression tests re-run after a change to make sure you didn’t break something that was already working.
Snapshot tests capture what a React component looks like and flag if it changes unexpectedly. There are even more types beyond these (performance, security, load testing), but they’re not relevant for us.

This week, we’re focusing on unit tests. They’re the fastest to write, the simplest to understand, and the foundation everything else builds on. Our project is set up with a testing library, so you can write a unit test for any component.

✅ Exercise 2: Write a unit test

Pick a component you built in a previous week. If you worked on Posts, test your Post component. If you worked on Events, test your Event component. This way everyone on your team is testing something different.
You should see a __tests__ folder in your project. If you don’t, create one — this is where your test files will live.
Create a test file for your component in that folder (e.g., Post.test.tsx or EventCard.test.tsx).
Ask Codex: "Write a simple unit test using Jest for a React component called [YourComponent] to ensure it renders without crashing."
Run the test from your terminal: pnpm run test
Did it pass? If so, you’ve just written your first test! 🎉
Commit it. This is real code that belongs in the repo — git add your test file and commit it with a message like "test: add unit test for Post component".

How to self-validate: The terminal will print a green PASS message next to your test file name. If it fails, Codex can read the error message and help you fix it!

3. Client-side state & Interactivity ⚡

Some features, like a search bar that filters a list in real-time, require interactivity on the client-side (in the browser). In Next.js, you can create a client-side component by putting the "use client" directive at the top of your file.

✅ Exercise 3: Prompting for client-side state

Tell Codex you need a client component:

"I need to build a search filter for a list of resources. This will require client-side state, so make sure this is a React client component."

Prompt for the state and the filter logic:

"I have an array of resource objects from the server. I need to use React’s useState hook to store a search query. Then, I need to filter the array based on the search query and display the filtered list."

How to self-validate: After you add the search component to your page, try typing a few letters into the input box. If the list of items below it instantly shrinks to match what you typed (without the page reloading), your client-side state is working perfectly!

4. Polishing layouts with Tailwind 🎨

Ticket #10 asks you to restyle the homepage with a real layout — not just a list. Tailwind makes this easier once you know a few key utilities: grid, flex, gap-*, and responsive prefixes like md: and lg:.

✅ Exercise 4: Build a two-column responsive layout

Open the homepage file (app/page.tsx).
Prompt Codex:

"Restyle this page using Tailwind so that on desktop (md and up), the community list is a two-column grid with a gap-6. On mobile, it should stack into a single column. Each community card should have a white background, rounded corners, padding, and a subtle shadow on hover."

Resize your browser window from wide to narrow to confirm the layout collapses cleanly.

How to self-validate: On a wide window you see two columns of cards. On a narrow window (or your phone) the cards stack into one column. Hover a card — it should have a subtle shadow effect.

5. Integrating external APIs 🔌

Not all data has to come from your own database. You can pull in data from thousands of other services using their APIs. This week, you’ll integrate the Giphy API to let users add GIFs to their posts!

When you use an external API, your API key must stay secret. If you put it in a client component, anyone can see it in their browser's Network tab. The solution is to create a proxy — a backend API route on your server that makes the request on behalf of the client.

✅ Exercise 5: Build an API Proxy

Let's practice the proxy pattern.

Prompt Codex:

"Create a Next.js API route at app/api/weather/route.ts that accepts a city query parameter, makes a fetch request to a weather API using a secret API key from process.env, and returns the result to the client."

How to self-validate: Visit localhost:3000/api/weather?city=NewYork in your browser. You should see JSON data. Open the browser's Network tab — you should NOT see the API key anywhere in the request.

🎟️ Your tickets for this week

This week is about taking your app from “it works” to “it feels like a real product.” Each of you will pick up one of these tickets:

Ticket #10: Style the Homepage Layout — Use Tailwind’s grid, flex, and responsive utilities to turn the basic homepage into a polished, mobile-friendly layout. Practice the patterns from Exercise 4. Then write a unit test for your styled component to verify it renders correctly.
Ticket #11: Add a Search Filter to Resources — Build a client-side search box that filters the resources list in real time as the user types. Practice the patterns from Exercise 3 ("use client", useState, filter logic). Then write a unit test for your search filter component to verify it renders correctly.
Ticket #12: Integrate the Giphy API for Posts — Let users add a GIF to their post. Use the API proxy pattern from Exercise 5 to keep your Giphy API key secret on the server. Then write a unit test for your GIF picker component to verify it renders correctly.

For the testing piece: ask Codex to write a unit test for the main component you built, run pnpm run test to confirm it passes, and commit the test file alongside your feature code. This is part of shipping professional code: the feature isn’t done until it’s tested.

If your team finishes early, the stretch tickets are #13 (Notifications) and #14 (Vercel Deployment), talk to your facilitator before picking those up.

Have fun with it! You’re almost done!