So I’ve decided to deeply refactor my helpers.
It’s always an interesting exercise, especially when it’s not your “primary” language.
Why bother with unit tests?
I suspected the forked implementation was incomplete.
I use Astro built-in helpers to retrieve data from markdown files.
It works fine, but how the heck do you test that?
Of course, e2e tests prevent broken UI.
However, that’s not enough.
You need unit tests to verify the internal logic.
Pretty hard when the code is tied to a specific framework, a.k.a. code you don’t control.
Tutorial hell vs. agnostic concepts
I did not find a lot of documentation on this topic.
That’s great, because that’s what beginners may regularly experience with search results, and now with AI platforms and agents.
How do you assess the quality of the generated code?
You don’t even know how to craft basic stuff, especially if it’s not your favorite programming language or if you’re a beginner.
Linters and other analyzers won’t catch everything.
This is where agnostic concepts can help:
- focus on behaviors, not the implementation details
- unit tests are meant to test your internal logic, and E2E tests are best suited for UI and interactions
- tests should not depend on code you don’t maintain
Good supervision is hard
If you ask AI about a specific bug, it will likely fix this bug using existing solutions:
How to fix “The collection does not exist” in unit tests for a project powered by Astro?
The answer might consist of using astro dev to regenerate the .astro/ folder, or blog posts might even recommend to simply use built-in Astro helpers in your tests, so you will rely on real content files all the time.
While it certainly works, it does not feel right, as you are actually focusing on Astro helpers instead of your own business logic.
Don’t get me wrong. It’s neither Astro nor AI’s fault.
If you’re not proficient enough in programming, you will likely skip fundamental principles, and there’s probably no way for you to realize you’ve just feeded AI with sloppy prompts, which explains why you get sloppy results.
You might not even realize your implementation is unoptimized, as it just works.
Problems will occur sooner or later, though, for example, when refactoring or extending code.
From naive implementation to mocks
I’ve refactored my previous naive implementation with mocks.
While the new implementation is not exactly the best ever, it’s still far better than the previous one, and my tests are now decoupled from the implementation details.
I can mock getCollection or getEntry to fill them with fake data instead of hitting real data every time.
While I’m not a JavaScript developer, I’m quite confident this is a more standardized and maintainable approach.
Write better prompts
AI platforms and agents are powerful, but most of them are aimed to satisfy your demand quickly, not to produce maintainable code by default, especially on free plans.
Providing more specific context does help, but it won’t inject the professional vision you need unless you actually ask for it.
In my experience, the following instructions can mitigate bad approaches:
use standard approach for this programmming language/framework
ensure I understand what I’m doing when asking for new code or refactoring my implementation
Be skeptical.
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.