Skip to content

Conversation

d-markey
Copy link

@d-markey d-markey commented Sep 20, 2025

Hello,

I've tried to use source_gen_test but found some limitations because my generator produces multiple outputs.

I have first modified (slightly) generateForElement to accept an optional custom BuildStep (the mock implementation caused crashes in my case). It should not be a breaking change, and it allowed me to test the main ourput using annotations from source_gen_test.

However, it didn't help for additional outputs. So I've added a new function generateForLibrary which can be used to generate code for a full library and return the build results to the caller, so further checks can be done. Right now, checks must be implemented in the test code.

I suppose adding more test annotations in source_gen_test could make the experience for generateForLibrary as streamlined as it is for generateForElement + @shouldGenerate*. But I haven't explored this for the time being. I'm happy enough with checking the generated code programmatically. Actually I think I'd be more interested in assessing the resulting object model or AST, making sure expected classes and methods are there while allowing for some differences due to implementation detail changes as the generator evolves.

Are you interested in accepting this pull request?

- Add support for `BuilderOptions` via a custom `TestBuildStep` implementation (handles patterns in `build_extensions` + multiple outputs). `TestBuildStep` stored generated code in memory.
- Implement `generateForLibrary()` to generate all outputs for the specified library (includes support for generating the golden files). Clients can inspect build outputs via the returned `TestBuildResults`.
- Normalize line-endings and paths for better support of Windows platforms.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant