Week 6: Testing Mindset and Safer Conventions

After weeks of wrestling with the QR scanner, I’ve managed to get it to a point where I can finally start focusing on testing, which feels like reaching a checkpoint in a marathon I didn’t know I signed up for. It wasn’t easy (many “why isn’t this working” moments), but with Dr. Shawn’s guidance, I slowly pieced it together.

With the scanner ready, my focus shifted from implementing features to implementing their tests. That’s where things got interesting. At first, testing felt like another layer of work, something that slowed me down, but tutorials and documentation slowly made the picture clearer. I’m still in the middle of figuring out the actual implementation, but what’s changing is my perspective: testing isn’t just about checking if things work, it’s about discovering the exact points where they might fail.

UUID vs UuidValue

Identifiers might sound boring, but this was one of my biggest lightbulb moments. I used to store jwtId as a plain string. It worked, until it didn’t. Strings don’t guarantee validity, and that left room for hidden bugs. Switching to a validated UUID object changed that completely:

• With UuidValue.withValidation, I can validate and store the UUID in a single step instead of parsing it and then discarding invalid inputs.
• Unlike Uuid, which is mainly a utility for generating or parsing UUIDs, UuidValue actually represents a real, validated UUID.

Takeaway: Using UuidValue ensures that invalid IDs never slip through, and strong typing plus built-in validation reduce hidden errors before they even begin.

Avoiding Hardcoded Prefixes

At first, I had values like "event:" written directly into my logic. Simple, right? But simple here was fragile. If the prefix ever changed, I’d have to hunt through the code to fix it, a future nightmare waiting to happen. By replacing it with a prefix constant, things instantly felt cleaner:

• Consistency, no matter what changes later.
• Safer trimming logic that won’t touch the wrong part.
• A clear line between database keys and domain IDs.

Takeaway: Replacing “magic strings” with constants makes the code clearer, safer, and easier to maintain.

Factorization That Matters

Alongside safer constants, I also thought about code organization and when refactoring actually helps.

• Breaking code into smaller functions can backfire if those functions don’t add clarity.
• For example, wrapping UI components into separate functions without real benefit just created extra noise.
• Refactoring should always aim to simplify the code, not make it harder to follow.

Takeaway: Refactor only when it improves clarity or reduces duplication, not just for structure’s sake.

Testing Philosophy

The most eye-opening moment came from a discussion about what testing really means. I used to think tests were mostly about proving that things work, but in reality, their real job is to show where they don’t.

• Tests should push boundaries, not just confirm happy paths.
• Edge cases and failure scenarios matter more than the “ideal” flow.
• The goal is to define the operational space where software can be trusted.
• Green checkmarks aren’t the goal, finding the breaks is.

Takeaway: Testing is about finding boundaries, not just confirming success.

Reflections & Insights

• Validated objects like UUIDs protect against hidden errors.
• Avoiding hardcoded values reduces fragility and makes future changes painless.
• Refactoring only has meaning when it improves clarity or functionality.
• Testing should focus on failure points, that’s where its real value lies.

These lessons remind me to prioritize safety and clarity, not just quick fixes. It’s a mindset I’ll carry into bigger features.

What’s Coming Up

Next, I’ll keep learning and implementing tests side by side, especially for the QR scanner with mocked database calls. The goal isn’t just to write code that works, but to prove it works under pressure.