Exploring the Concept
I had to realize that my original plan—to develop my own TypeSpec emitter and Go code generator—led me too far away from
my actual goal. The realignment—building Go code directly from OpenAPI specs using ogen—now gives me a clean and
stable foundation.
Even though Spec CLI coordinates the creation process with TypeSpec and ogen, the focus remains clearly on
testing. I won’t abstract away ogen’s core competency; its types and functions flow directly into Spec CLI and
remain visible. There’s no reason to introduce unnecessary wrappers here. If I ever hit limitations, I’ll assess case by
case whether to optimize the generated code locally via AST or submit a pull request to the upstream project.
Technology-Agnostic Mocks
Although the entire project is tailored to my Go focus, the test components are completely decoupled. Ultimately, the mocks operate independently of the technology being used. I build my test setups using Docker Compose, for example; but regardless of which tooling is involved—the mocks remain a standalone instance and can be addressed by any client.
Conclusion
The idea of providing my own code generator would have been thematically very appealing, but it doesn’t address the core of my problem and would have completely shifted the project’s focus.
Recognizing that a custom generator, while technically alluring, is strategically a rabbit hole reflects a healthy, pragmatic approach. By using
ogentypes directly, you avoid the classic problem of leaky abstractions and keep the toolchain lean. Decoupling the mocks also ensures that Spec CLI delivers real value even in polyglot environments.