@alexeagle, took another stab with a different API.

• Instead of the test key we'd now use a tests key that supports multiple key entries

tests:
  default:
     Var1: val1
     Var2: val2
  test2: 
     Var1: val1
     Var2: val2

• Different command for tests instead of using a flag, so scaffold test ...
• Allow for rendering into an in memory file system
• Allow for outputting an AST (this is how we do our internal testing)
• Allow for running specific cases with --case flag

Example AST Output

scaffold test --log-level="panic" --case="default" --memfs --ast <scaffold-name>
scaffold-test-3811:  (type=dir)
        main.go:  (type=file)
                package main

                import (
                        "fmt"
                )

                func main() {
                        fmt.Println("Hello, World!")
                }

Neat! Thanks :)

An idea for generalizing just a bit:

Since the tests block appears in the same scaffold file that users might inspect to see "what prompts does this ask", do you think this feature might also be useful for users to discover the tests, but not use them to assert correctness. Instead the user could skip some of the prompts by choosing "canned" answers for some or all of them. In that case just renaming tests to presets would make this appear more useful for that use case.

Personally I wouldn't add a new test command here, because you're not giving a way for me to exercise the system-under-test nor make assertions. In the "Arrange, Act, Assert" model, this only provides "Arrange". I think the new command with a flag would keep complexity lower, with proposal above

scaffold new https://github.com/hay-kot/scaffold-go-cli --preset my-preset-1

I'm pretty happy with how the API turned out. Going to write some better documentation and write a few more tests this weekend so hopefully it'll be merged and released by Monday.

Thanks for all your feedback, it was very helpful!