Okay, I have to admit I went into this with sky-high expectations. I'd heard Continue was magic for generating boilerplate code, so I dedicated our last two-week sprint to using it specifically for beefing up our unit test coverage. Here’s my honest breakdown.
**The Good:**
* The speed for creating initial test skeletons was unreal. I'd highlight a function, ask Continue to write a Jest test for it, and bam—basic structure with a few sensible test cases was there in seconds.
* It was fantastic for generating mock data and setting up complex test fixtures. Saved me so much time typing out repetitive `mockReturnValue` chains.
* It helped me discover edge cases I hadn't considered. Asking "what are some edge cases for this function?" often gave me a couple of useful test ideas I'd missed.
**The Not-So-Good:**
* The tests often felt... generic. They'd pass, but they didn't always reflect *our* specific business logic or failure scenarios. I spent a lot of time refining them to be meaningful.
* It sometimes got confused with our project's context. For example, it would suggest testing a module with a direct import when we actually use a dependency injection pattern, leading to failing tests.
* The biggest time sink was the "refinement loop." I'd ask for a change, it would make it, but then break something else in the test. It required very precise, incremental prompting.
**My Workflow & Takeaways:**
I ended up settling into a pattern:
1. Use Continue to generate the initial test scaffold and mocks.
2. Manually rewrite or adjust the test logic to match our actual use cases.
3. Use it again to quickly add "happy path" and "sad path" variants once I had one solid test.
For me, it was less of an "autopilot" and more of a "super-powered pair programmer who needs clear direction." It dramatically cut down the initial drudgery, but didn't replace the need for thoughtful test design.
Has anyone else tried using Continue specifically for testing? What was your experience? Did you find a prompting style that worked better than others?
🌻 fiona
null
Interesting. You mentioned spending time refining the generic tests to fit your business logic. Did you find the time spent on refinement still gave you a positive ROI compared to writing from scratch?
Also, on the context confusion with dependency injection, were you using a custom Continue configuration or just the defaults? I'm considering a trial but need to justify the setup time.
The "generic" tests thing really resonates. I found myself falling into a trap where I'd get a green checkmark on a mediocre test and mentally move on, only to realize later that the test was basically just exercising the happy path with no real assertions.
For me, the biggest time sink wasn't even refining the logic - it was realizing I had a false sense of security. I'd see 20 new tests passing and think "great, coverage is up" but then a bug slipped through because the test was just checking that a function returned _something_ instead of the _right thing_.
> "it would suggest testing a module with a direct import when we actually use a dependency injection pattern"
This killed me on a project using Inversify. Continue kept generating tests that instantiated classes directly instead of going through the container. Ended up writing a custom prompt template that explicitly called out our DI pattern, which helped a bit but still wasn't perfect.
What's your approach for catching those "passes but meaningless" tests? Code review? Or do you have some metric you track?
Pipeline Pilot